Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Mihai Chira]

@Chris we tested the normal ANT build of the originally donated code.
Sorry that I don't have time to test the new versions.

On 2 September 2014 12:22, Christofer Dutz  wrote:
> @Mihai: Are you testing the Mavenized version or simply the output of the 
> normal ANT build?
>
> Chris
>
> 
> Von: Mihai Chira 
> Gesendet: Dienstag, 2. September 2014 12:42
> An: dev@flex.apache.org
> Betreff: Re: [DISCUSSION] Squiggly 1.0 release candidate 0
>
> I hope so. But from what I remember (and I wasn't the main developer
> dealing with this), the flex version of the project depended on
> classes inside the non-flex version, which means that if the wrong
> compiler argument was used, it would also replace the flex-SpellUI
> with the non-flex-SpellUI. But again, things may have changed a lot
> since then.
>
> On 2 September 2014 11:38, Justin Mclean  wrote:
>> Hi,
>>
>>> Even if this is not a problem anymore, it might be worth adding a new
>>> step to the release verification process to create a project without
>>> Flex and make sure that squiggly works well, and the same for a Flex
>>> project.
>>
>> I think this is just a matter of including the right swcs and not all of 
>> them?
>>
>> Thanks,
>> Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Mihai Chira]

I hope so. But from what I remember (and I wasn't the main developer
dealing with this), the flex version of the project depended on
classes inside the non-flex version, which means that if the wrong
compiler argument was used, it would also replace the flex-SpellUI
with the non-flex-SpellUI. But again, things may have changed a lot
since then.

On 2 September 2014 11:38, Justin Mclean  wrote:
> Hi,
>
>> Even if this is not a problem anymore, it might be worth adding a new
>> step to the release verification process to create a project without
>> Flex and make sure that squiggly works well, and the same for a Flex
>> project.
>
> I think this is just a matter of including the right swcs and not all of them?
>
> Thanks,
> Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Even if this is not a problem anymore, it might be worth adding a new
> step to the release verification process to create a project without
> Flex and make sure that squiggly works well, and the same for a Flex
> project.

I think this is just a matter of including the right swcs and not all of them?

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Mihai Chira]

I wanted to add two things related to squiggly, in order of importance:

1. (Sorry if I'm stating the obvious:) There are two versions of the
class SpellUI.as - one of flex projects and one for projects which
don't include the Flex framework. We had a big problem when we tried
to compile the project (using the ant script at the time - they were
exactly the versions donated by Adobe, I'm sure things changed since
then), because it used external-library-path instead of
include-libraries to compile, which meant that instead of keeping the
SpellUI for flex projects, which we needed, it kept the one for
projects without Flex. Using include-libraries fixed it.

Even if this is not a problem anymore, it might be worth adding a new
step to the release verification process to create a project without
Flex and make sure that squiggly works well, and the same for a Flex
project.

2. There is a memory leak in both version of SpellUI.as[1]. I won't
have time to fix it anytime soon, but in case anyone has some free
time on their hands, it could be useful to release without the leak.

[1] https://issues.apache.org/jira/browse/FLEX-34421

On 2 September 2014 02:29, Justin Mclean  wrote:
> Hi,
>
>> Don't know if it is a blocker. I can ask legal. I'm just wondering if the 
>> current text properly indicates the permissive license for English.
>
> I really don't think you need to ask legal again but if you really feel you 
> need to go ahead. We as a PMC should be able to decide, and in it's 
> discovered later we've made a mistake we can correct it. Worse case it will 
> be "fixed" in the next release anyway.
>
> We're talking about changes to a README (not LICENSE or NOTICE) for something 
> that isn't even in the release. The user can download any dictionary they 
> choose (which come under a variety of licenses) we have no control over that.
>
> Thanks,
> Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Don't know if it is a blocker. I can ask legal. I'm just wondering if the 
> current text properly indicates the permissive license for English.

I really don't think you need to ask legal again but if you really feel you 
need to go ahead. We as a PMC should be able to decide, and in it's discovered 
later we've made a mistake we can correct it. Worse case it will be "fixed" in 
the next release anyway.

We're talking about changes to a README (not LICENSE or NOTICE) for something 
that isn't even in the release. The user can download any dictionary they 
choose (which come under a variety of licenses) we have no control over that.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

Don't know if it is a blocker. I can ask legal. I'm just wondering if the 
current text properly indicates the permissive license for English.
Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.

Justin Mclean  wrote:


Hi,

> The concern:  The README points folks to openoffice.org and
> http://hunspell.sourceforge.net.

And in your view is this a blocker and requires another release candidate or 
can we fix in the next release?

> 1) Are we sure it is ok to add the asdoc into the source package?

There is no requirement to put it in a separate package and most apache 
projects don't have separate zip for docs, http seems about the only exception 
and in it's case that makes sense you don't normally deploy docs about http 
server live. IMO With a library you do want the docs with the source so that 
people using the code know how to use it.

> I would have to add those files as exceptions during a RAT run to get clean
> results.

You can ignore them or pass a -e or -E option to rat.

> 2) And if you do decide to tweak that, should the binary packages be in a
> binaries folder on dist?

Again there is no requirement to do that and it varies from project to project 
/ release to release how the release area is organised.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> And ... when preparing the next RC ... if you could do a RELEASE run, we 
> could stage our first Release as Maven artifacts too.

The current SNAPSHOP needs to be reviewed first.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> The concern:  The README points folks to openoffice.org and
> http://hunspell.sourceforge.net.

And in your view is this a blocker and requires another release candidate or 
can we fix in the next release?

> 1) Are we sure it is ok to add the asdoc into the source package?

There is no requirement to put it in a separate package and most apache 
projects don't have separate zip for docs, http seems about the only exception 
and in it's case that makes sense you don't normally deploy docs about http 
server live. IMO With a library you do want the docs with the source so that 
people using the code know how to use it.

> I would have to add those files as exceptions during a RAT run to get clean
> results.

You can ignore them or pass a -e or -E option to rat.

> 2) And if you do decide to tweak that, should the binary packages be in a
> binaries folder on dist?

Again there is no requirement to do that and it varies from project to project 
/ release to release how the release area is organised.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

On 9/1/14 1:56 AM, "Justin Mclean"  wrote:

>Hi,
>
>> My apologies for this going so long.  Basically, all we need now is a
>> ruling from legal-discuss as to whether the license for Kevin Atkinson
>>is
>> considered BSD or MIT or otherwise Apache-compatible.
>
>And that now been confirmed by legal so all is good with the release
>candidate. Unless anyone has any other objections?
Squiggly has been legally cleared for take-off!

Now that we know it gets to fly solo, I have one concern, then some stuff
to consider:

The concern:  The README points folks to openoffice.org and
http://hunspell.sourceforge.net.  The dictionaries at open office.org and
the dictionaries linked to at Hunspell's site seem to be LPGL versions for
English.  How about we tweak the README by replacing:

You can obtain dictionary files from:
http://extensions.openoffice.org
http://hunspell.sourceforge.net";

With:

You can obtain en_US and en_CA dictionaries under a BSD/MIT-like
license from:
http://wordlist.aspell.net/dicts/

You can obtain other dictionary files from:
http://wordlist.aspell.net/other-dicts/

http://extensions.openoffice.org
http://hunspell.sourceforge.net";

But note that many of these dictionaries are under LPGL licenses.

Then if we do another RC, I'm wondering:


1) Are we sure it is ok to add the asdoc into the source package?  I would
have to add those files as exceptions during a RAT run to get clean
results.  I was expecting a separate zip in a doc folder on dist like we
do in the SDK.  After all, it isn't really source?
2) And if you do decide to tweak that, should the binary packages be in a
binaries folder on dist?
3) Could the README end with the same "thank you" we have in the SDK's
README?
Thanks for using Apache Flex.  Enjoy!

The Apache Flex Project


Other than that, I'm good to go. LICENSE and NOTICE and RELEASE_NOTES look
good and the build completed.

-Alex

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> My apologies for this going so long.  Basically, all we need now is a
> ruling from legal-discuss as to whether the license for Kevin Atkinson is
> considered BSD or MIT or otherwise Apache-compatible.

And that now been confirmed by legal so all is good with the release candidate. 
Unless anyone has any other objections?

I also sent an email to Kevin (1/2 hour ago) and he replied confirming that it 
is BSD/MIT (like). Given that it is we could actually bundled it into  a future 
release. Kevin has no objections if we do that.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

My apologies for this going so long.  Basically, all we need now is a
ruling from legal-discuss as to whether the license for Kevin Atkinson is
considered BSD or MIT or otherwise Apache-compatible.

Should be over as soon as we get the ruling.

-Alex

On 9/1/14 12:14 AM, "Erik de Bruin"  wrote:

>This is another one for the (yet to be implemented)
>legal-disc...@flex.apache.org mailing list :-(
>
>Apparently there are two (or more) interpretations possible. Either agree
>to disagree and toss a coin, or ask someone who can break the tie to take
>a
>look, and move on, please.
>
>EdB
>
>
>
>On Mon, Sep 1, 2014 at 9:04 AM, Justin Mclean 
>wrote:
>
>> Hi,
>>
>> > To be safe, we should probably get a ruling from legal-dicuss on the
>> SCOWL
>> > dictionaries.
>>
>> No ruling is required, there are no incompatible licences, all
>> dictionaries are based on word lists in the public domian and/or
>>licenses
>> unencumbered by rights that would be incompatable with Apache.
>>
>> But more importantly none are licenced under any licence listed in
>> Category X (GPL, NPL, BCL etc).
>>
>> I'll also note that we are not even bundling this dictionary and other
>> dictionaries exist that are also licensed by a license not in Category
>>X.
>>
>> Here is the copyright/licence for the complete list of things in the
>>SCOWL
>> package, the english dictionary uses a subset of these licences.
>>
>> Again I see no licences that are incompatible and there are no Category
>>X
>> licences.
>>
>> The collective work is Copyright 2000-2014 by Kevin Atkinson as well
>> as any of the copyrights mentioned below:
>>
>>   Copyright 2000-2014 by Kevin Atkinson
>>
>>   Permission to use, copy, modify, distribute and sell these word
>>   lists, the associated scripts, the output created from the scripts,
>>   and its documentation for any purpose is hereby granted without fee,
>>   provided that the above copyright notice appears in all copies and
>>   that both that copyright notice and this permission notice appear in
>>   supporting documentation. Kevin Atkinson makes no representations
>>   about the suitability of this array for any purpose. It is provided
>>   "as is" without express or implied warranty.
>>
>> Alan Beale  also deserves special credit as he has,
>> in addition to providing the 12Dicts package and being a major
>> contributor to the ENABLE word list, given me an incredible amount of
>> feedback and created a number of special lists (those found in the
>> Supplement) in order to help improve the overall quality of SCOWL.
>>
>> The 10 level includes the 1000 most common English words (according to
>> the Moby (TM) Words II [MWords] package), a subset of the 1000 most
>> common words on the Internet (again, according to Moby Words II), and
>> frequently class 16 from Brian Kelk's "UK English Wordlist
>> with Frequency Classification".
>>
>> The MWords package was explicitly placed in the public domain:
>>
>> The Moby lexicon project is complete and has
>> been place into the public domain. Use, sell,
>> rework, excerpt and use in any way on any platform.
>>
>> Placing this material on internal or public servers is
>> also encouraged. The compiler is not aware of any
>> export restrictions so freely distribute world-wide.
>>
>> You can verify the public domain status by contacting
>>
>> Grady Ward
>> 3449 Martha Ct.
>> Arcata, CA  95521-4884
>>
>> gr...@netcom.com
>> gr...@northcoast.com
>>
>> The "UK English Wordlist With Frequency Classification" is also in the
>> Public Domain:
>>
>>   Date: Sat, 08 Jul 2000 20:27:21 +0100
>>   From: Brian Kelk 
>>
>>   > I was wondering what the copyright status of your "UK English
>>   > Wordlist With Frequency Classification" word list as it seems to
>>   > be lacking any copyright notice.
>>
>>   There were many many sources in total, but any text marked
>>   "copyright" was avoided. Locally-written documentation was one
>>   source. An earlier version of the list resided in a filespace called
>>   PUBLIC on the University mainframe, because it was considered public
>>   domain.
>>
>>   Date: Tue, 11 Jul 2000 19:31:34 +0100
>>
>>   > So are you saying your word list is also in the public domain?
>>
>>   That is the intention.
>>
>> The 20 level includes frequency classes 7-15 from Brian's word list.
>>
>> The 35 level includes frequency classes 2-6 and words appearing in at
>> least 11 of 12 dictionaries as indicated in the 12Dicts package.  All
>> words from the 12Dicts package have had likely inflections added via
>> my inflection database.
>>
>> The 12Dicts package and Supplement is in the Public Domain.
>>
>> The WordNet database, which was used in the creation of the
>> Inflections database, is under the following copyright:
>>
>>   This software and database is being provided to you, the LICENSEE,
>>   by Princeton University under the following license.  By obtaining,
>>   using and/or copying this software and database, you agree 

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Apparently there are two (or more) interpretations possible.

Nope in this case it's quite clear cut. Either SCOWL contains a Category X 
license or not.

Every single other objection that has raised has been sorted by the discussion 
on legal and the current RC still complies with Apache licensing.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

It's all very confusing to me.  It isn't my call.  I have asked for a
ruling from legal-discuss.  It is odd that other products like AOO haven't
switched to this dictionary.

Once they give us the green light, we'll be all set.

-Alex


On 9/1/14 12:04 AM, "Justin Mclean"  wrote:

>Hi,
>
>> To be safe, we should probably get a ruling from legal-dicuss on the
>>SCOWL
>> dictionaries. 
>
>No ruling is required, there are no incompatible licences, all
>dictionaries are based on word lists in the public domian and/or licenses
>unencumbered by rights that would be incompatable with Apache.
>
>But more importantly none are licenced under any licence listed in
>Category X (GPL, NPL, BCL etc).
>
>I'll also note that we are not even bundling this dictionary and other
>dictionaries exist that are also licensed by a license not in Category X.
>
>Here is the copyright/licence for the complete list of things in the
>SCOWL package, the english dictionary uses a subset of these licences.
>
>Again I see no licences that are incompatible and there are no Category X
>licences.
>
>The collective work is Copyright 2000-2014 by Kevin Atkinson as well
>as any of the copyrights mentioned below:
>
>  Copyright 2000-2014 by Kevin Atkinson
>
>  Permission to use, copy, modify, distribute and sell these word
>  lists, the associated scripts, the output created from the scripts,
>  and its documentation for any purpose is hereby granted without fee,
>  provided that the above copyright notice appears in all copies and
>  that both that copyright notice and this permission notice appear in
>  supporting documentation. Kevin Atkinson makes no representations
>  about the suitability of this array for any purpose. It is provided
>  "as is" without express or implied warranty.
>
>Alan Beale  also deserves special credit as he has,
>in addition to providing the 12Dicts package and being a major
>contributor to the ENABLE word list, given me an incredible amount of
>feedback and created a number of special lists (those found in the
>Supplement) in order to help improve the overall quality of SCOWL.
>
>The 10 level includes the 1000 most common English words (according to
>the Moby (TM) Words II [MWords] package), a subset of the 1000 most
>common words on the Internet (again, according to Moby Words II), and
>frequently class 16 from Brian Kelk's "UK English Wordlist
>with Frequency Classification".
>
>The MWords package was explicitly placed in the public domain:
>
>The Moby lexicon project is complete and has
>been place into the public domain. Use, sell,
>rework, excerpt and use in any way on any platform.
>
>Placing this material on internal or public servers is
>also encouraged. The compiler is not aware of any
>export restrictions so freely distribute world-wide.
>
>You can verify the public domain status by contacting
>
>Grady Ward
>3449 Martha Ct.
>Arcata, CA  95521-4884
>
>gr...@netcom.com
>gr...@northcoast.com
>
>The "UK English Wordlist With Frequency Classification" is also in the
>Public Domain:
>
>  Date: Sat, 08 Jul 2000 20:27:21 +0100
>  From: Brian Kelk 
>
>  > I was wondering what the copyright status of your "UK English
>  > Wordlist With Frequency Classification" word list as it seems to
>  > be lacking any copyright notice.
>
>  There were many many sources in total, but any text marked
>  "copyright" was avoided. Locally-written documentation was one
>  source. An earlier version of the list resided in a filespace called
>  PUBLIC on the University mainframe, because it was considered public
>  domain.
>
>  Date: Tue, 11 Jul 2000 19:31:34 +0100
>
>  > So are you saying your word list is also in the public domain?
>
>  That is the intention.
>
>The 20 level includes frequency classes 7-15 from Brian's word list.
>
>The 35 level includes frequency classes 2-6 and words appearing in at
>least 11 of 12 dictionaries as indicated in the 12Dicts package.  All
>words from the 12Dicts package have had likely inflections added via
>my inflection database.
>
>The 12Dicts package and Supplement is in the Public Domain.
>
>The WordNet database, which was used in the creation of the
>Inflections database, is under the following copyright:
>
>  This software and database is being provided to you, the LICENSEE,
>  by Princeton University under the following license.  By obtaining,
>  using and/or copying this software and database, you agree that you
>  have read, understood, and will comply with these terms and
>  conditions.:
>
>  Permission to use, copy, modify and distribute this software and
>  database and its documentation for any purpose and without fee or
>  royalty is hereby granted, provided that you agree to comply with
>  the following copyright notice and statements, including the
>  disclaimer, and that the same appear on ALL copies of the software,
>  database and documentation, including modifications that you make
>  for internal use or for distribution.
>
>  WordNet 1

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Erik de Bruin]

This is another one for the (yet to be implemented)
legal-disc...@flex.apache.org mailing list :-(

Apparently there are two (or more) interpretations possible. Either agree
to disagree and toss a coin, or ask someone who can break the tie to take a
look, and move on, please.

EdB



On Mon, Sep 1, 2014 at 9:04 AM, Justin Mclean 
wrote:

> Hi,
>
> > To be safe, we should probably get a ruling from legal-dicuss on the
> SCOWL
> > dictionaries.
>
> No ruling is required, there are no incompatible licences, all
> dictionaries are based on word lists in the public domian and/or licenses
> unencumbered by rights that would be incompatable with Apache.
>
> But more importantly none are licenced under any licence listed in
> Category X (GPL, NPL, BCL etc).
>
> I'll also note that we are not even bundling this dictionary and other
> dictionaries exist that are also licensed by a license not in Category X.
>
> Here is the copyright/licence for the complete list of things in the SCOWL
> package, the english dictionary uses a subset of these licences.
>
> Again I see no licences that are incompatible and there are no Category X
> licences.
>
> The collective work is Copyright 2000-2014 by Kevin Atkinson as well
> as any of the copyrights mentioned below:
>
>   Copyright 2000-2014 by Kevin Atkinson
>
>   Permission to use, copy, modify, distribute and sell these word
>   lists, the associated scripts, the output created from the scripts,
>   and its documentation for any purpose is hereby granted without fee,
>   provided that the above copyright notice appears in all copies and
>   that both that copyright notice and this permission notice appear in
>   supporting documentation. Kevin Atkinson makes no representations
>   about the suitability of this array for any purpose. It is provided
>   "as is" without express or implied warranty.
>
> Alan Beale  also deserves special credit as he has,
> in addition to providing the 12Dicts package and being a major
> contributor to the ENABLE word list, given me an incredible amount of
> feedback and created a number of special lists (those found in the
> Supplement) in order to help improve the overall quality of SCOWL.
>
> The 10 level includes the 1000 most common English words (according to
> the Moby (TM) Words II [MWords] package), a subset of the 1000 most
> common words on the Internet (again, according to Moby Words II), and
> frequently class 16 from Brian Kelk's "UK English Wordlist
> with Frequency Classification".
>
> The MWords package was explicitly placed in the public domain:
>
> The Moby lexicon project is complete and has
> been place into the public domain. Use, sell,
> rework, excerpt and use in any way on any platform.
>
> Placing this material on internal or public servers is
> also encouraged. The compiler is not aware of any
> export restrictions so freely distribute world-wide.
>
> You can verify the public domain status by contacting
>
> Grady Ward
> 3449 Martha Ct.
> Arcata, CA  95521-4884
>
> gr...@netcom.com
> gr...@northcoast.com
>
> The "UK English Wordlist With Frequency Classification" is also in the
> Public Domain:
>
>   Date: Sat, 08 Jul 2000 20:27:21 +0100
>   From: Brian Kelk 
>
>   > I was wondering what the copyright status of your "UK English
>   > Wordlist With Frequency Classification" word list as it seems to
>   > be lacking any copyright notice.
>
>   There were many many sources in total, but any text marked
>   "copyright" was avoided. Locally-written documentation was one
>   source. An earlier version of the list resided in a filespace called
>   PUBLIC on the University mainframe, because it was considered public
>   domain.
>
>   Date: Tue, 11 Jul 2000 19:31:34 +0100
>
>   > So are you saying your word list is also in the public domain?
>
>   That is the intention.
>
> The 20 level includes frequency classes 7-15 from Brian's word list.
>
> The 35 level includes frequency classes 2-6 and words appearing in at
> least 11 of 12 dictionaries as indicated in the 12Dicts package.  All
> words from the 12Dicts package have had likely inflections added via
> my inflection database.
>
> The 12Dicts package and Supplement is in the Public Domain.
>
> The WordNet database, which was used in the creation of the
> Inflections database, is under the following copyright:
>
>   This software and database is being provided to you, the LICENSEE,
>   by Princeton University under the following license.  By obtaining,
>   using and/or copying this software and database, you agree that you
>   have read, understood, and will comply with these terms and
>   conditions.:
>
>   Permission to use, copy, modify and distribute this software and
>   database and its documentation for any purpose and without fee or
>   royalty is hereby granted, provided that you agree to comply with
>   the following copyright notice and statements, including the
>   disclaimer, and that the same appear on ALL copies of 

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> To be safe, we should probably get a ruling from legal-dicuss on the SCOWL
> dictionaries. 

No ruling is required, there are no incompatible licences, all dictionaries are 
based on word lists in the public domian and/or licenses unencumbered by rights 
that would be incompatable with Apache.

But more importantly none are licenced under any licence listed in Category X 
(GPL, NPL, BCL etc).

I'll also note that we are not even bundling this dictionary and other 
dictionaries exist that are also licensed by a license not in Category X.

Here is the copyright/licence for the complete list of things in the SCOWL 
package, the english dictionary uses a subset of these licences.

Again I see no licences that are incompatible and there are no Category X 
licences.

The collective work is Copyright 2000-2014 by Kevin Atkinson as well
as any of the copyrights mentioned below:

  Copyright 2000-2014 by Kevin Atkinson

  Permission to use, copy, modify, distribute and sell these word
  lists, the associated scripts, the output created from the scripts,
  and its documentation for any purpose is hereby granted without fee,
  provided that the above copyright notice appears in all copies and
  that both that copyright notice and this permission notice appear in
  supporting documentation. Kevin Atkinson makes no representations
  about the suitability of this array for any purpose. It is provided
  "as is" without express or implied warranty.

Alan Beale  also deserves special credit as he has,
in addition to providing the 12Dicts package and being a major
contributor to the ENABLE word list, given me an incredible amount of
feedback and created a number of special lists (those found in the
Supplement) in order to help improve the overall quality of SCOWL.

The 10 level includes the 1000 most common English words (according to
the Moby (TM) Words II [MWords] package), a subset of the 1000 most
common words on the Internet (again, according to Moby Words II), and
frequently class 16 from Brian Kelk's "UK English Wordlist
with Frequency Classification".

The MWords package was explicitly placed in the public domain:

The Moby lexicon project is complete and has
been place into the public domain. Use, sell,
rework, excerpt and use in any way on any platform.

Placing this material on internal or public servers is
also encouraged. The compiler is not aware of any
export restrictions so freely distribute world-wide.

You can verify the public domain status by contacting

Grady Ward
3449 Martha Ct.
Arcata, CA  95521-4884

gr...@netcom.com
gr...@northcoast.com

The "UK English Wordlist With Frequency Classification" is also in the
Public Domain:

  Date: Sat, 08 Jul 2000 20:27:21 +0100
  From: Brian Kelk 

  > I was wondering what the copyright status of your "UK English
  > Wordlist With Frequency Classification" word list as it seems to
  > be lacking any copyright notice.

  There were many many sources in total, but any text marked
  "copyright" was avoided. Locally-written documentation was one
  source. An earlier version of the list resided in a filespace called
  PUBLIC on the University mainframe, because it was considered public
  domain.

  Date: Tue, 11 Jul 2000 19:31:34 +0100

  > So are you saying your word list is also in the public domain?

  That is the intention.

The 20 level includes frequency classes 7-15 from Brian's word list.

The 35 level includes frequency classes 2-6 and words appearing in at
least 11 of 12 dictionaries as indicated in the 12Dicts package.  All
words from the 12Dicts package have had likely inflections added via
my inflection database.

The 12Dicts package and Supplement is in the Public Domain.

The WordNet database, which was used in the creation of the
Inflections database, is under the following copyright:

  This software and database is being provided to you, the LICENSEE,
  by Princeton University under the following license.  By obtaining,
  using and/or copying this software and database, you agree that you
  have read, understood, and will comply with these terms and
  conditions.:

  Permission to use, copy, modify and distribute this software and
  database and its documentation for any purpose and without fee or
  royalty is hereby granted, provided that you agree to comply with
  the following copyright notice and statements, including the
  disclaimer, and that the same appear on ALL copies of the software,
  database and documentation, including modifications that you make
  for internal use or for distribution.

  WordNet 1.6 Copyright 1997 by Princeton University.  All rights
  reserved.

  THIS SOFTWARE AND DATABASE IS PROVIDED "AS IS" AND PRINCETON
  UNIVERSITY MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
  IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, PRINCETON
  UNIVERSITY MAKES NO REPRESENTATIONS OR WARRANTIES OF MERCHANT-
  ABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE
 

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

On 8/31/14 11:14 PM, "Justin Mclean"  wrote:

>Hi,
>
>So given that the two objections you just raised we already comply with
>(ie That not all dictionaries out there are Category X and we do know of
>an English dictionary with an Apache compatible license) can we move
>forward now?
To be safe, we should probably get a ruling from legal-dicuss on the SCOWL
dictionaries.  I'll put the details in the legal-discuss thread.

-Alex

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

So given that the two objections you just raised we already comply with (ie 
That not all dictionaries out there are Category X and we do know of an English 
dictionary with an Apache compatible license) can we move forward now?

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> "If you want just a spell-checker package, then that is fine. You just
> can't produce something that requires Category X (whether build or run
> time)."

And Squiggly doesn't require anything that is Category X. The dictionaries come 
in many licences, it just seems most are LGPL.

This is no different to how we teat fonts, people can use what ever font they 
want (include GPL ones) in their flex applications, however we can't bundled a 
LGPL or non Adobe compatible license font in a release.

> I don't think this is the case, so I think he's saying we can't release it
> unless we could find or create an english dictionary that isn't category X.

We already have, see the SCOWL link in the same the legal discussion. [1]

Justin

1.http://wordlist.aspell.net/dicts/

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

It still isn't clear to me.  I asked for more clarification.  Here are two
parts of the last reply on legal-discuss:

"If you want just a spell-checker package, then that is fine. You just
can't produce something that requires Category X (whether build or run
time)."

First he says we can have a package, but then says we can't if it requires
Category X, which for practical purposes, this RC does.

"Justin: to answer your question: I would expect the English spell-checker
to be available under ASF/permissive licensing. The primary language of
the product community is English, and so I would expect that to be
available. If not... then it doesn't seem like a permissively-licensed
project."


I don't think this is the case, so I think he's saying we can't release it
unless we could find or create an english dictionary that isn't category X.

-Alex

On 8/31/14 10:19 PM, "Justin Mclean"  wrote:

>Hi,
>
>So given the reply on legal would now agree we can release as a separate
>package and we can move forward with the vote on the RC?
>
>Thanks,
>Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

So given the reply on legal would now agree we can release as a separate 
package and we can move forward with the vote on the RC?

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

I guess we see it differently.  The two answers we got seemed to conflict.
 I've asked for clarification on legal-discuss.

On 8/31/14 9:35 PM, "Justin Mclean"  wrote:

>Hi,
>
>> My understanding of the legal-discuss thread is that we cannot.
>
>My understanding is that  we can.
>
>Given other projects have done similar things with Hunspell lets move
>forward with the release and if and when Legal come back with a clear
>decision we can (if required) fix any issues they identify. We are not
>including any LGPL code or are we forcing users to download LGPL code.
>
>>  We have to bundle the code in some other release like the Flex SDK
>>where it
>> Squiggly's capabilities can be seen as an optional feature.
>
>Squiggky is an optional feature and we can release it on it own. I see no
>need to complicate matters and package it in the SDK and in fact that may
>cause other (legal and otherwise) issues.
>
>Thanks,
>Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> My understanding of the legal-discuss thread is that we cannot.

My understanding is that  we can.

Given other projects have done similar things with Hunspell lets move forward 
with the release and if and when Legal come back with a clear decision we can 
(if required) fix any issues they identify. We are not including any LGPL code 
or are we forcing users to download LGPL code.

>  We have to bundle the code in some other release like the Flex SDK where it
> Squiggly's capabilities can be seen as an optional feature.

Squiggky is an optional feature and we can release it on it own. I see no need 
to complicate matters and package it in the SDK and in fact that may cause 
other (legal and otherwise) issues.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

I guess I don't understand.  You think the PMC should vote to approve a
release that only contains Squiggly?

My understanding of the legal-discuss thread is that we cannot.  We have
to bundle the code in some other release like the Flex SDK where it
Squiggly's capabilities can be seen as an optional feature.

I will ask for verification on legal-discuss.

-Alex

On 8/31/14 3:19 PM, "Justin Mclean"  wrote:

>Hi,
>
>> The lucene link looks like it is doc for a java package of classes, not
>>a
>> separate file in the release artifact.
>
>It generated from the source and is in the release.
>
>> IMO, we can link to link AOO
>
>Which is exactly what we are doing in the RC.
>
>> Remember that the Flex SDK already has a category X dependency for the
>> optional embedded font jars.  The code that calls the category X jars is
>> bundled in the one and only release artifact, but the code is set up
>>such
>> that those category X jars can be missing.
>
>Which is exactly what the Squiggly release candidate is doing ie you can
>compile it even if the dictionary files are missing.
>
>>  The mentors ruled that was sufficient because nobody "must" download
>>the category X jars to
>> successfully use the Flex SDK.
>
>And the Squiggly release candidate doesn't force you to to download any
>category X jars (or in this case LGPL data). So again we are in
>compliance..
>
>>  I would expect we would do the same for Squiggly.
>
>We are.
>
>> But if you want, we can ask on the legal-discuss thread.
>
>There is nothing that needs to be asked as the matter is resolved. Alex
>if you think it's not please put it to a VOTE.
>
>If and when legal come up with a clear response we'll abide by that and
>change if required how Squiggly is packackaged, or make it download LGPL
>code.
>
>And can people please take a look at the RC to see if there are any other
>issues we need to fix up.
>
>Thanks,
>Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> The lucene link looks like it is doc for a java package of classes, not a
> separate file in the release artifact.

It generated from the source and is in the release.

> IMO, we can link to link AOO

Which is exactly what we are doing in the RC.

> Remember that the Flex SDK already has a category X dependency for the
> optional embedded font jars.  The code that calls the category X jars is
> bundled in the one and only release artifact, but the code is set up such
> that those category X jars can be missing.

Which is exactly what the Squiggly release candidate is doing ie you can 
compile it even if the dictionary files are missing.

>  The mentors ruled that was sufficient because nobody "must" download the 
> category X jars to
> successfully use the Flex SDK.

And the Squiggly release candidate doesn't force you to to download any 
category X jars (or in this case LGPL data). So again we are in compliance..

>  I would expect we would do the same for Squiggly.

We are.

> But if you want, we can ask on the legal-discuss thread.

There is nothing that needs to be asked as the matter is resolved. Alex if you 
think it's not please put it to a VOTE. 

If and when legal come up with a clear response we'll abide by that and change 
if required how Squiggly is packackaged, or make it download LGPL code.

And can people please take a look at the RC to see if there are any other 
issues we need to fix up.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

The lucene link looks like it is doc for a java package of classes, not a
separate file in the release artifact.

IMO, we can link to link AOO or offer downloads in the ant
scripts/installer.  I think the second key question is, does the code that
calls/uses the category X code/data need to be in a separate file or not.
Remember that the Flex SDK already has a category X dependency for the
optional embedded font jars.  The code that calls the category X jars is
bundled in the one and only release artifact, but the code is set up such
that those category X jars can be missing.  The mentors ruled that was
sufficient because nobody "must" download the category X jars to
successfully use the Flex SDK.  I would expect we would do the same for
Squiggly.  Just bundling the code should be ok because you can still use
the rest of the Flex SDK.  But if you want, we can ask on the
legal-discuss thread.

-Alex

On 8/31/14 12:21 AM, "Justin Mclean"  wrote:

>Hi,
>
>Or even better this link:
>https://lucene.apache.org/core/4_0_0/analyzers-common/org/apache/lucene/an
>alysis/hunspell/package-summary.html
>
>Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Eventually it could utilize Flex' runtime loaded resource-bundles?
Not that I can see, the format, while text based, is very different.

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> I’m not sure if there’s any way to include languages that optionally download 
> at runtime.

You specify the language via the SpellingConfig.xml files, that's loaded at 
runtime then dictionaries specified in that file are loaded at runtime. So you 
can have no dictionaries, user defined dictionaries, or externally licensed 
dictionaries. As far as I know they need to be local in the project and can't 
be downloaded from external locations. (May not to be too hard to change.)

> Having to include every possible language at compile time is a deal-breaker 
> for me.

No languages are specified at compile time.

> That’s a few hundred KB per language that I cannot afford.

Try Mb / language for a complete list of words :-)

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Harbs]

I’ve never used Squiggly, but I would like to — with one caveat.

I’m not sure if there’s any way to include languages that optionally download 
at runtime. Having to include every possible language at compile time is a 
deal-breaker for me. That’s a few hundred KB per language that I cannot afford.

Harbs

On Aug 31, 2014, at 12:35 PM, Christofer Dutz  wrote:

> You can automate the deployment of SNAPSHOT versions using Apache Jenkins 
> Credentials. It's simply that they have vonfigured Jenkins to use a 
> settings.xml in which the server tags are filled with the credentials of a 
> technical user we can use to deploy stuff.
> 
> Releases can never be automatic as all releases have to go to a special 
> staging repo.
> 
> Regarding the working of the distribution ... well I only take binaries and 
> copy them and add a text file. If the dependency structure you named works, 
> so shoud the snapshots. 
> 
> I would like to ask someone who actually uses Squiggly to eventually give 
> this a test drive. I have no idea how to use it ... as far as I understood 
> it's an "online spell checker thigy" ... correct? ;-)
> 
> Chris
> 
> 
> -Ursprüngliche Nachricht-
> Von: Justin Mclean [mailto:jus...@classsoftware.com] 
> Gesendet: Sonntag, 31. August 2014 03:26
> An: dev@flex.apache.org
> Betreff: Re: [DISCUSSION] Squiggly 1.0 release candidate 0
> 
> Hi,
> 
>> Glad that it's now working :-)
> 
> Well making a snapshop and the snapshop and 100% working may be two different 
> things. Mind checking the contents for me?
> 
>> When running on the Apache Jenkins this automatically works.
> 
> Good to know, but making a release is still a manual process right via 
> https://oss.sonatype.org?
> 
> Thanks,
> Justin
> 

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

Or even better this link:
https://lucene.apache.org/core/4_0_0/analyzers-common/org/apache/lucene/analysis/hunspell/package-summary.html

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Lucerne does exactly what we are doing (as far as I can see).

Sorry wrong link - try this link instead:
https://code.google.com/p/lucene-hunspell/

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> What is preventing us from doing what Apache Open Office is doing here?

Basically they got special permission to bundle (L)GPL dictionaries, see 
https://issues.apache.org/jira/browse/LEGAL-117,  but yes you right they also 
link to them.

Lucerne does exactly what we are doing (as far as I can see).
https://lucenenet.apache.org/docs/3.0.3/d2/da4/_hunspell_stem_filter_8cs_source.html

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[OmPrakash Muppirala]

What is preventing us from doing what Apache Open Office is doing here?

http://extensions.openoffice.org/en/project/english-dictionaries-apache-openoffice

Thanks,
Om


On Sat, Aug 30, 2014 at 11:52 PM, Justin Mclean 
wrote:

> Hi,
>
> > We would have to bundle the source with the SDK and vote on a new SDK
> release.
> Wouldn't that also be in violation? And actually force the component to be
> non optional, unless you count having it installed but not using it as non
> optional?
>
> Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> We would have to bundle the source with the SDK and vote on a new SDK release.
Wouldn't that also be in violation? And actually force the component to be non 
optional, unless you count having it installed but not using it as non optional?

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

There's a key question to be answered on legal-discuss, which is whether
we are in violation of the guidelines by releasing a package that doesn't
bundle or download Category X and just telling folks where to get the
Category X data.  Henri said Yes, Greg implied no (with the
runtime-dependency answer).

If the answer is no, then my understanding is that we cannot vote on a
separate Squiggly release package.  We would have to bundle the source
with the SDK and vote on a new SDK release.

-Alex


On 8/30/14 9:42 PM, "Justin Mclean"  wrote:

>Hi Alex,
>
>Given legal advice currently is:
>1. If I cannot run Apache Flex without acquiring that (L)GPL data, then
>it violates the guidelines.
>2. making it an optional feature is a great and perfectly acceptable
>solution
>3. Flex's ActionScript spellchecker would not include the LGPL/GPL
>dictionaries and would instead only provide instructions on how to obtain
>them
>
>And that the current RC complies with 1 and 3 and 2 is acceptable (and
>what you suggested). What if anything needs to be change in the RC to
>make it comply?
>
>As far as I can see nothing further is required - other than perhaps add
>a note saying so the README (just to make it clear), and then add it as
>as optional download in the installer at some later date.
>
>Also can other PMC members please check the RC1 for any other issues.
>
>Thanks,
>Justin
>
>

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi Alex,

Given legal advice currently is:
1. If I cannot run Apache Flex without acquiring that (L)GPL data, then it 
violates the guidelines.
2. making it an optional feature is a great and perfectly acceptable solution
3. Flex's ActionScript spellchecker would not include the LGPL/GPL dictionaries 
and would instead only provide instructions on how to obtain them

And that the current RC complies with 1 and 3 and 2 is acceptable (and what you 
suggested). What if anything needs to be change in the RC to make it comply?

As far as I can see nothing further is required - other than perhaps add a note 
saying so the README (just to make it clear), and then add it as as optional 
download in the installer at some later date.

Also can other PMC members please check the RC1 for any other issues.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Glad that it's now working :-)

Well making a snapshop and the snapshop and 100% working may be two different 
things. Mind checking the contents for me?

> When running on the Apache Jenkins this automatically works.

Good to know, but making a release is still a manual process right via 
https://oss.sonatype.org?

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> ant -f maven.xml 

Works for me now - thanks.

> Would start to deploy the SNAPSHOT artifacts to Apaches Snapshot repo.

I have given that a try:
https://repository.apache.org/content/repositories/snapshots/org/apache/flex/squiggly/

Want to confirm everything looks good in there?

Given you need to add your credentials to an XML file is there a way to safely 
automate SNAPSHOTS (ie equiv to nightly builds) I'm think down the track where 
a SNAPSHOP of the SDK may be useful to some people. Do we manually have to make 
and deploy snapshots every day if we wanted it to match the nightly build?

> When preparing a release-candidate you would set the "type" property to 
> "RELEASE" and it would use a release version and deploy to Apaches Staging 
> repo.

By editing the line  in maven.xml 
right? And you would need to do that before releasing the RC as we want these 
XML files to go into the release right? (otherwise the md5s sig wouldn't match 
if you tried to replicate the build). I note [1] says NOTICE and LICENSE files 
should be present in the META-INF directory within the jar - are we doing that?

> Here they can be viewed and tested and as soon as all is ok and the 
> release-candidate passes it's vote.

How do you do that?  looks like you need to go to https://oss.sonatype.org and 
manually do it? Is there another way?

Thanks,
Justin

1. http://www.apache.org/dev/publishing-maven-artifacts.html#staging-maven

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

On 8/30/14 1:51 AM, "Justin Mclean"  wrote:

>Hi,
>
>> From folks who have been in the ipmc longer and advise on whether this
>>is a category x dependency.
>
>Looks like the question has already been answered, and it probably legal
>rather than incubator who would need to answer if we think it is an issue.
Good suggestion to ask on legal-discuss first.  I will do that shortly.
For me, the concern comes from this section in legal-resolved [1]:

--
Can Apache projects rely on components whose licensing affects the Apache
product?Apache projects cannot distribute any such components. However, if
the component is only needed for optional features, a project can provide
the user with instructions on how to obtain and install the non-included
work. Optional means that the component is not required for standard use
of the product or for the product to achieve a desirable level of quality.
The question to ask yourself in this situation is:

* "Will the majority of users want to use my product without adding the
optional components?"
--


Lucene and AOO are not spell-checking products.  They can be used without
adding dictionaries.  If we bundled Squiggly with the SDK, then I will
also get confirmation from legal-discuss, but I would argue that he
majority of users can use the SDK without downloading the dictionaries.
But if the product is simply a spell-checker...

Anyway, we'll see what legal-discuss has to say.

[1] http://www.apache.org/legal/resolved.html#category-x

-Alex

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> That was exactly what I was looking for ... thanks :-)

I'm currently getting:
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project 
[unknown-group-id]:[unknown-artifact-id]:[unknown-version] 
(/Users/justinmclean/Documents/ApacheFlexUtilitiesGit/Squiggly/main/maven.xml) 
has 4 errors
[ERROR] Malformed POM 
/Users/justinmclean/Documents/ApacheFlexUtilitiesGit/Squiggly/main/maven.xml: 
Unknown attribute 'default' for tag 'project' (position: START_TAG seen ...\n  
limitations under the License.\n\n-->\n... @20:28)  
@ /Users/justinmclean/Documents/ApacheFlexUtilitiesGit/Squiggly/main/maven.xml, 
line 20, column 28 -> [Help 2]
[ERROR] 'groupId' is missing. @ line 20, column 28
[ERROR] 'artifactId' is missing. @ line 20, column 28
[ERROR] 'version' is missing. @ line 20, column 28
[ERROR] 

What am I doing wrong?

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> From folks who have been in the ipmc longer and advise on whether this is a 
> category x dependency.

Looks like the question has already been answered, and it probably legal rather 
than incubator who would need to answer if we think it is an issue.

1. https://code.google.com/p/lucene-hunspell/
"Note: we do not aim to produce or include any of these language support files, 
which are available under a variety of licenses and maintained elsewhere. We 
aim to produce the language-independent code to support the file format, with 
features geared specifically towards full-text search."

Here's some code that use it, note Apache license, this is equiv to our 
situation IMO.
https://lucenenet.apache.org/docs/3.0.3/d2/da4/_hunspell_stem_filter_8cs_source.html

2. Apache Open Office actually distributes LGPL dictionaries in their binaries 
(much to my surprise).

The OO bug on GPL dictionaries (include legal advice from the FSF on the issue)
https://issues.apache.org/ooo/show_bug.cgi?id=65039

But this is probably more relevant:
https://issues.apache.org/jira/browse/LEGAL-117
https://issues.apache.org/jira/browse/LEGAL-192

3. The a fair amount of discussion on legal mailing list about this - so the 
answer may already be there.
http://markmail.org/search/?q=list%3Aorg.apache.legal+dictionary

4. Interesting asides / reading.
some legal opinion on Hunspell dictionaries:
http://lwn.net/Articles/481386/
Webster is a generic term for a dictionary and the dictionary is now actually 
public domain:
http://en.wikipedia.org/wiki/Webster%27s_Dictionary#The_name_Webster_used_by_others

5. There are non GLP dictionaries available, some of the ones mozilla use for 
instance
http://www.opentaal.org/bestanden
http://sourceforge.net/projects/openoffice-lv/
http://files.akl.lt/ispell-lt/
ftp://scon155.phys.msu.ru/pub/russian/ispell/LICENSE

Didn't find an English one however - so perhaps we should ship it with the 
Russian one above? :-)

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

>From folks who have been in the ipmc longer and advise on whether this is a 
>category x dependency.
Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.

Justin Mclean  wrote:


Hi,

> Do you think we need confirmation before proceeding?
Confirmation of exactly what and from who?

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Do you think we need confirmation before proceeding?  
Confirmation of exactly what and from who?

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

Do you think we need confirmation before proceeding?  I think we should.
Practically speaking, how many folks will be able to use the release
without downloading a category X file?

For fonts, you can definitely use Flex without having to download a
category X font.

-Alex

On 8/29/14 7:21 AM, "Justin Mclean"  wrote:

>Hi,
>
>> Doesn't that create a dependency on category x?
>
>Don't think so, it's more a dependency on a file format not a specific
>bit of software, basically the same as a font file. eg Flex (and users of
>flex) can use lots of different fonts, but we could only bundled a small
>subset of fonts that are licensed correctly.
>
>Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Doesn't that create a dependency on category x?

Don't think so, it's more a dependency on a file format not a specific bit of 
software, basically the same as a font file. eg Flex (and users of flex) can 
use lots of different fonts, but we could only bundled a small subset of fonts 
that are licensed correctly.

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

>  we have 7 swcs and I bet there are dependencies.
Some of the swcs are dependent on the others.

ApacheFlexLinguisticUtils.swc
ApacheflexSpellingEngine.swc
ApacheFlexSpellingFramework.swc -> ApacheFlexLinguisticUtils.swc + 
ApacheflexSpellingEngine.swc
ApacheFlexSpellingUI.swc -> ApacheFlexLinguisticUtils.swc + 
ApacheFlexSpellingEngine.swc + ApacheFlexSpellingFramework.swc
ApacheFlexSpellingUIAPI.swc -> ApacheflexLinguisticUtils.swc + 
ApacheFlexSpellingEngine.swc + ApacheFlexSpellingFramework.swc
ApacheFlexSpellingUITLF.swc -> ApacheFlexLinguisticUtils.swc + 
ApacheFlexSpellingEngine.swc + ApacheFlexSpellingFramework.swc + 
ApacheFlexSpellingUI.swc
ApacheFlexSpellingUIEx.swc -> ApacheFlexLinguisticUtils.swc + 
ApacheFlexSpellingEngine.swc + ApacheFlexSpellingFramework.swc + 
ApacheFlexSpellingUI.swc

Does that help?

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

>  Hunspell format which is the same format as MySpell which is based on 
> Ispell. 

And I should of said Ispell is ancient  [1] - " Ispell has a very long history 
that can be traced back to a program that was originally written in 1971 in 
PDP-10 Assembly language". That predates my programming experience, I've only 
programmed a PDP-11.

Again it's the data format that we use here:
"The generalized affix description system introduced by ispell has since been 
imitated by other spelling checkers such as MySpell."

Thanks,
Justin

1. http://en.wikipedia.org/wiki/Ispell

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> To use Squiggly, is the Hunspell dictionaries included at compile time or is 
> it downloaded at runtime (or something else)?

Hunspell is not actually required at all, a dictionary may be required (if 
specified) and that dictionary is in Hunspell format which is the same format 
as MySpell which is based on Ispell.  The ANE which is not in this release uses 
I believe the  C++ version of Hunspell.

For Flex at runtime the SpellingConfig.xml is loaded and from that it loads the 
dictionaries specified in the that file.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Could someone here quickly write down how the squiggly artifacts depend on 
> each other and extenal dependencies?
Basically there are no complication dependancies other than you need the Flex 
SDK (ie mxml and asdoc) to compile it. The ANE not in this release would 
require air.

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Harbs]

To use Squiggly, is the Hunspell dictionaries included at compile time or is it 
downloaded at runtime (or something else)?

On Aug 29, 2014, at 1:24 AM, Justin Mclean  wrote:

>> I am wondering how Hunspell is integrated here?  Was it a port from C++ to
>> AS3?
> 
> I'm not 100% sure but from whatI can tell the AS version supports Hunspell 
> dictionaries, and the ANE version (not in this release) uses Hunspell. I 
> don't think there's a port of Hunspell in the current release.

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

Doesn't that create a dependency on category x?
Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.

Justin Mclean  wrote:


Hi,

> I'm wondering if any of the dictionaries have no GPL components.  If we
> can't find one that does, that may mean that Squiggly cannot be its own
> release package.

>From a brief look I couldn't find one, so for now I think we just need to 
>point people in the right direction.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

>> Well it's a SWC isn't it? 
> 
> Several swcs - look in the libs directory.
> 
>> Eventually all we have to do is write a pom with it's dependencies and an 
>> Apache header, repo, license block etc and manually stage that RC in the 
>> staging repo.
> 
> Just the swcs or the code as well? Given this is reasonably simple what would 
> the pom look like?

Raised a JIRA for this:
https://issues.apache.org/jira/browse/FLEX-34508

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> I'm wondering if any of the dictionaries have no GPL components.  If we
> can't find one that does, that may mean that Squiggly cannot be its own
> release package.

From a brief look I couldn't find one, so for now I think we just need to point 
people in the right direction.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

>>> 1.  There are two README files, one here [1] and one under the 'main'
>>> directory after unzipping the src/binary kit.  We should merge those two,
>>> to avoid confusion.

Done

>>> 5.  The apps under main/Demo/ does not seem to work

Until we can package a dictionary I've removed them from the release packages.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> I am wondering how Hunspell is integrated here?  Was it a port from C++ to
> AS3?

I'm not 100% sure but from whatI can tell the AS version supports Hunspell 
dictionaries, and the ANE version (not in this release) uses Hunspell. I don't 
think there's a port of Hunspell in the current release.

>  The C++ library seems to be an GPL/LGPL/MPL tri-license [1] (whatever
> that means)   Does it matter in terms of what goes in the NOTICE or LICENSE
> files?

The licence means that if it was included we could only include the MPL version 
in binary form and not include the source.

> You are right.  No need to change the package names.  We definitely don't
> want to break existing code.But, what exactly did you change then?

The sub project directory names and a few file example names.

> "Error #2044: Unhandled ioError:. text=Error #2032: Stream Error. URL:
> app:/"

That's probably it failing to load the dictionary as it's missing. If you try 
the example I posted and obtain a en_US dictionary you see it works.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[OmPrakash Muppirala]

On Thu, Aug 28, 2014 at 4:33 AM, Justin Mclean 
wrote:

> Hi,
>
> > 1.  There are two README files, one here [1] and one under the 'main'
> > directory after unzipping the src/binary kit.  We should merge those two,
> > to avoid confusion.
> Can do.
>

Thanks!


>
> > 2.  LICENSE file is incomplete (there is a TODO section in there)
> Git issue and it's been fixed, there's no additional licences. As far as I
> can see there's no need to anything additional that need to be added to
> LICENSE. Anyone think otherwise?
>

I am wondering how Hunspell is integrated here?  Was it a port from C++ to
AS3?  The C++ library seems to be an GPL/LGPL/MPL tri-license [1] (whatever
that means)   Does it matter in terms of what goes in the NOTICE or LICENSE
files?


>
> > 3.  I still see the 'Adobe' name in package names, ex.
> > SpellingUI/src/com/adobe ...
> We've not changed adobe package names in the past - are you saying we
> should now? Note that this would break existing user applications.
>

You are right.  No need to change the package names.  We definitely don't
want to break existing code.But, what exactly did you change then?


>
> > I thought this was fixed?  Was the RC made before this fix?
> Most of the directory names were fixed before the RC, a few files and
> directory were missed and have not been renamed.
>
> > 4.  The genTextWordlist.sh script under main/Data does not work.
> I'll take a look but may be a donation issue.
>

Not a blocker, IMO.  Perhaps we should add a note in the RELEASE_NOTES that
this does not work yet?


>
> > 5.  The apps under main/Demo/ does not seem to work
> In what way? How did you try and compile them? Example apps may need some
> modifications re config files and more likely  missing dictionaries - which
> were removed form the donation. Should we try and fix them or remove from
> the release?
>


I imported them into a Flash Builder project.  First there was an error
about the app descriptor; looks like it is a really old version of AIR.
After fixing that, there was a runtime error about  a missing
'AdobeSpellingConfig.xml'.  I copied it from another project into my
bin-debug directory.  Now it is throwing a generic error without much
details:

"Error #2044: Unhandled ioError:. text=Error #2032: Stream Error. URL:
app:/"

We should either remove the Demo directory from the release or at least,
make a note in RELEASE_NOTES that they dont work yet.

Thanks,
Om

[1] http://hunspell.sourceforge.net/


> Thanks,
> Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

On 8/28/14 4:54 AM, "Justin Mclean"  wrote:

>Hi,
>
>> When I was prepping the donation, I was thinking we'd send folks to
>> Hunspell to get their dictionaries.
>
>Open Office extensions may be a better option being an Apache project?
>Looks like if you unziip an OO dictionary you get the files you need.
Hmm.  OO sure sounded like a better option, but I just went there and
looked at the README for en_US, and it appears that one of the files you
get still appears to be LPGL.

I'm wondering if any of the dictionaries have no GPL components.  If we
can't find one that does, that may mean that Squiggly cannot be its own
release package.  It might have to become an optional feature of the SDK.
I'm guessing that's how AOO can use Hunspell.

-Alex

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> Well it's a SWC isn't it? 

Several swcs - look in the libs directory.

> Eventually all we have to do is write a pom with it's dependencies and an 
> Apache header, repo, license block etc and manually stage that RC in the 
> staging repo.

Just the swcs or the code as well? Given this is reasonably simple what would 
the pom look like?

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> When I was prepping the donation, I was thinking we'd send folks to
> Hunspell to get their dictionaries.

Open Office extensions may be a better option being an Apache project? Looks 
like if you unziip an OO dictionary you get the files you need.

>  We could provide links, or maybe the
> ant script can offer to fetch one (with notification of license
> differences first).

From a brief looks most seem to be GPL so may be some issues there.

Thanks,
Jus

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> As we noticed with FlexUnit that simply releasing Maven artifacts of a 
> previously released library isn't that easy (From Apache procedures ... the 
> releasing itself is easy), I think we should think about releasing the maven 
> artifacts together with the normal release.

So how do we release both at once? And do users actually need a mavenized 
version of Squiggly?

Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

> 1.  There are two README files, one here [1] and one under the 'main'
> directory after unzipping the src/binary kit.  We should merge those two,
> to avoid confusion.
Can do.

> 2.  LICENSE file is incomplete (there is a TODO section in there)
Git issue and it's been fixed, there's no additional licences. As far as I can 
see there's no need to anything additional that need to be added to LICENSE. 
Anyone think otherwise?

> 3.  I still see the 'Adobe' name in package names, ex.
> SpellingUI/src/com/adobe ...
We've not changed adobe package names in the past - are you saying we should 
now? Note that this would break existing user applications.

> I thought this was fixed?  Was the RC made before this fix?
Most of the directory names were fixed before the RC, a few files and directory 
were missed and have not been renamed.

> 4.  The genTextWordlist.sh script under main/Data does not work.
I'll take a look but may be a donation issue.

> 5.  The apps under main/Demo/ does not seem to work
In what way? How did you try and compile them? Example apps may need some 
modifications re config files and more likely  missing dictionaries - which 
were removed form the donation. Should we try and fix them or remove from the 
release?

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[OmPrakash Muppirala]

MD5 and signature looks good.
Compiles fine

I see some issues:

1.  There are two README files, one here [1] and one under the 'main'
directory after unzipping the src/binary kit.  We should merge those two,
to avoid confusion.
 2.  LICENSE file is incomplete (there is a TODO section in there)
3.  I still see the 'Adobe' name in package names, ex.
SpellingUI/src/com/adobe ...
I thought this was fixed?  Was the RC made before this fix?
4.  The genTextWordlist.sh script under main/Data does not work.  Throws
this error:

$ ./genTextWordlist.sh
cat: squigglyWordlist/*: No such file or directory

5.  The apps under main/Demo/ does not seem to work

Thanks,
Om

[1] https://dist.apache.org/repos/dist/dev/flex/squiggly/1.0/rc0/README


On Wed, Aug 27, 2014 at 11:59 PM, Alex Harui  wrote:

> When I was prepping the donation, I was thinking we'd send folks to
> Hunspell to get their dictionaries.  We could provide links, or maybe the
> ant script can offer to fetch one (with notification of license
> differences first).
>
> BTW, I ran out of time tonight to look at the RC.  I'll look in my morning
> and should have info by the time I normally see your first emails.
>
> -Alex
>
> On 8/27/14 9:21 PM, "Justin Mclean"  wrote:
>
> >Hi,
> >
> >While not a blocker, the main inconvenience I see with the current RC is
> >that is requirement the user to source a dictionary, as none were
> >provided in Adobe's donation. While it easy enough to take one from
> >Adobe's version of Squiggly that's not exactly optimal.  What can we do
> >about this? Obvious at the very least we need to add it to the
> >README/RELEASE_NOTES
> >
> >Does anyone know what Open Office does? I think they use (perhaps use to
> >use?) the same dictionary format.
> >
> >Thanks,
> >Justin
>
>

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Alex Harui]

When I was prepping the donation, I was thinking we'd send folks to
Hunspell to get their dictionaries.  We could provide links, or maybe the
ant script can offer to fetch one (with notification of license
differences first).

BTW, I ran out of time tonight to look at the RC.  I'll look in my morning
and should have info by the time I normally see your first emails.

-Alex

On 8/27/14 9:21 PM, "Justin Mclean"  wrote:

>Hi,
>
>While not a blocker, the main inconvenience I see with the current RC is
>that is requirement the user to source a dictionary, as none were
>provided in Adobe's donation. While it easy enough to take one from
>Adobe's version of Squiggly that's not exactly optimal.  What can we do
>about this? Obvious at the very least we need to add it to the
>README/RELEASE_NOTES
>
>Does anyone know what Open Office does? I think they use (perhaps use to
>use?) the same dictionary format.
>
>Thanks,
>Justin

RE: [DISCUSSION] Squiggly 1.0 release candidate 0

[Glenn Willianms]

Great

I have a largish project im maintaining that uses it and will grab rc0 and
see how it goes.
 Thanks for taking time to get this into good shape

glenn

-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com] 
Sent: 28 August 2014 02:13
To: dev@flex.apache.org
Subject: [DISCUSSION] Squiggly 1.0 release candidate 0

Hi,

Please place all of the discussion here rather than in the the thread.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

HI,

Just in case anyone needs a simple test to try it out:
http://www.adobe.com/2006/mxml"; layout="vertical">









SpellingConfig.xml:

  


You need to provide en_US.aff and en_US.dic file and place in a data directory 
but these can be found in many places. eg Adobe's version of Squiggly or it 
looks like from the Open Office extensions site [1]

Thanks,
Justin

1. http://extensions.openoffice.org

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

While not a blocker, the main inconvenience I see with the current RC is that 
is requirement the user to source a dictionary, as none were provided in 
Adobe's donation. While it easy enough to take one from Adobe's version of 
Squiggly that's not exactly optimal.  What can we do about this? Obvious at the 
very least we need to add it to the README/RELEASE_NOTES

Does anyone know what Open Office does? I think they use (perhaps use to use?) 
the same dictionary format.

Thanks,
Justin

Re: [DISCUSSION] Squiggly 1.0 release candidate 0

[Justin Mclean]

Hi,

A few things to consider:
- More instructions on how to use would be useful (could we get permission to 
use content from here?) [1]
- Do we need debug and non debug swc binary versions?
- Do we require ASDocs to be part of the first release or can that wait until a 
later release?
- Should we rename / get rid of main?

Thanks,
Justin

1. http://labs.adobe.com/technologies/squiggly/releasenotes.html