Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

I just added some MIT / BSD dictionaries to Squiggly and modified the LICENSE in what I think is is accordance with their license. Any objections to what I've done here before we (eventually in a month or so) come around to making a new release.

https://github.com/apache/flex-utilities/blob/develop/Squiggly/LICENSE

Thanks,
Justin

Re: Squiggly dictionaries license

[Alex Harui <ah...@adobe.com>]

OK, I will ask for approval on legal-discuss.

On 9/24/14 11:25 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> IMO, we either use the entire license, or use a pointer, and if we use a
>> pointer, it should follow the template in the how-to.  Can you explain
>>why
>> we shouldn't use the pointer template in the how-to?
>
>Because it meets minimal legal requirements and is not a licensing error.
>
>> Can you explain, given that the responder on legal-discuss did not say
>>the
>> current LICENSE was ok and made a suggestion for a change, you do not
>>want
>> to change the current LICENSE?
>
>They did not say the current license was incorrect either.
>
>Justin

Re: Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> IMO, we either use the entire license, or use a pointer, and if we use a
> pointer, it should follow the template in the how-to.  Can you explain why
> we shouldn't use the pointer template in the how-to?

Because it meets minimal legal requirements and is not a licensing error.

> Can you explain, given that the responder on legal-discuss did not say the
> current LICENSE was ok and made a suggestion for a change, you do not want
> to change the current LICENSE?

They did not say the current license was incorrect either.

Justin

Re: Squiggly dictionaries license

[Alex Harui <ah...@adobe.com>]

On 9/24/14 11:12 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> only a portion of the dictionary README is copied into the Squiggly
>>LICENSE.
>
>That's incorrect there's currently a pointer to the long form.
IMO, we either use the entire license, or use a pointer, and if we use a
pointer, it should follow the template in the how-to.  Can you explain why
we shouldn't use the pointer template in the how-to?

Can you explain, given that the responder on legal-discuss did not say the
current LICENSE was ok and made a suggestion for a change, you do not want
to change the current LICENSE?

-Alex

Re: Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> only a portion of the dictionary README is copied into the Squiggly LICENSE.

That's incorrect there's currently a pointer to the long form.

Justin

Re: Squiggly dictionaries license

[Alex Harui <ah...@adobe.com>]

On 9/24/14 10:27 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> I looked again this morning.  Is there something I was supposed to get
>> from that? 
>
>Yes look at the license "pointer" for the dictionaries are set up.
>https://github.com/apache/openoffice/blob/trunk/main/LICENSE_aggregated

I'm sorry, I still don't know what I'm supposed to learn from this that
supports the current text of the Squiggly license.  IMO, since the last
line of LICENSE_aggregated says "make sure to add the license here" and
Open Office is using the practice of having long LICENSE files, that would
imply that you would copy the entire README into LICENSE as I suggested as
option 1 and was suggested by the responder on legal-discuss.  Right now
only a portion of the dictionary README is copied into the Squiggly
LICENSE.

-Alex

Re: Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I looked again this morning.  Is there something I was supposed to get
> from that? 

Yes look at the license "pointer" for the dictionaries are set up.
https://github.com/apache/openoffice/blob/trunk/main/LICENSE_aggregated

Thanks,
Justin

Re: Squiggly dictionaries license

[Alex Harui <ah...@adobe.com>]

I looked again this morning.  Is there something I was supposed to get
from that?  I did not see anything that would make me think the current
text in flex-utilities/Squiggly/LICENSE is correct.  IMO, there are two
choices:

1) go against the folks who prefer short licenses and include the entire
Hunspell README in the LICENSE.
2) Use a simple pointer without copyright or excerpt from the README as
described in the how-to such as:

This product bundles SCOWL and Friends dictionaries, which are available
under a
"BSD/MIT-like" license.  For details, see
dictionaries/en_US/README_en_US.txt or dictionaries/en_GB/README_en_GB.txt.


Either one is fine with me. Open Office definitely leads the way in long
licenses.  I think what we have right now is at best misleading as one
could be fooled into thinking the excerpt is the complete license.  I know
you have additional text above saying to look for more details, but I
don't understand why we wouldn't want to use the template.  Every time we
try to create our own wording we run the risk of doing it wrong, and the
response on legal-discuss did not say the current text is correct.

-Alex

On 9/24/14 7:58 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>Did you actually look at the links/reachearch or what currently in Git?
>In particular look at the aggregated files from Open Office.
>
>Does what we currently have meet the minimum legal requirements? And if
>it doesn't exactly what requirement are we not meeting?
>
>Thanks
>Justin

Re: Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

Did you actually look at the links/reachearch or what currently in Git? In particular look at the aggregated files from Open Office.

Does what we currently have meet the minimum legal requirements? And if it doesn't exactly what requirement are we not meeting?

Thanks
Justin

Re: Squiggly dictionaries license

[Alex Harui <ah...@adobe.com>]

My conclusion, based on reply on the legal-discuss thread is that we
should either use a pointer or include the entire license, but not just
the portion that talks about the collection.  IOW, it wouldn't be right
for someone to take an Apache LICENSE file that references third-party
content and other licenses and only include the Apache portion and not the
rest.  

I do agree no change to NOTICE is required.

-Alex

On 9/21/14 1:04 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>Looking in legal it seem the short vs long license hasn't been fully
>resolved and there's a few different views on it ie see [1] which has
>been reopened. However both Roy [1] [2] and the licence how to [3]  and
>this [4] say short licences / pointers are preferred.
>
>The (short) discussion on legal around the Squiggly license hasn't
>brought up any objections to the current LICENSE and NOTICE and confirms
>that we shouldn't add anything to NOTICE. Although even that may also be
>considered unresolved [5], there seems to be mostly consensus on this
>[6]. I think some of the confusion here is that when you remove a
>copyright header from a file and replace it with an Apache one then you
>do need to add the copyright to the NOTICE file, and in some case people
>have added copyright notices to to NOTICE when the headers have remained
>the same, but that isn't legally required other than in a few rare cases.
>[6]
>
>Current consensus is to a) use license pointers, b) keep licences as
>short, c) keep stuff out of NOTICE unless legally required (as it impacts
>downstream projects). a and b are optional ie you can still use the full
>licence if you want, but still meet the legal requirements. It's also
>clear than MIT/BSD (3 clause) licensed software do not need to be added
>to NOTICE [3] (even though some projects have done this).
>
>The only legal JIRA I can find on aggregation is with open office and
>deals with the aggregation of LGPL dictionaries. [7] In the end they were
>allowed to included the LGPL dictionaries in their binary releases. They
>have chosen to use full licence text in their LICENSE file (2000 lines
>long!) [8] and have included more than what's the minimal legally
>required in their NOTICE [9]. But interestingly the dictionaries in
>questions are not even mentioned in LICENSE or NOTICE but instead are
>have short text without pointers in separate LICENSE [10] and NOTICE
>files [11]. This is a little different to our situation as it's for LGPL
>licence code which is normally not allowed to be included in Apache
>software.
>
>I think the only conclusion is that there is not a single right way to do
>this and I think the best way forward to basically leave the license as
>it is (with some minor word changes suggested by Alex) until we find out
>otherwise and then change if needed. We are complying with the minimal
>legal requirements and currently practice (ie use license pointers and
>MIT/BSD don't modify NOTICE) but probably have a little more in LICENSE
>than the legal minimum but that's not a licensing error.
>
>Thanks,
>Justin
>
>1. https://issues.apache.org/jira/browse/LEGAL-155
>2. 
>http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C
>CBFE3722-1B5C-48FC-AD82-0931EEC6F143@gbiv.com%3E
>3. http://www.apache.org/dev/licensing-howto.html#permissive-deps
>4. 
>http://apache.org/dev/release.html#distributing-code-under-several-license
>s
>5. https://issues.apache.org/jira/browse/LEGAL-59
>6. https://issues.apache.org/jira/browse/LEGAL-62
>7. https://issues.apache.org/jira/browse/LEGAL-117
>8. https://github.com/apache/openoffice/blob/trunk/main/LICENSE
>9. https://github.com/apache/openoffice/blob/trunk/main/NOTICE
>10. 
>https://github.com/apache/openoffice/blob/trunk/main/LICENSE_aggregated
>11. https://github.com/apache/openoffice/blob/trunk/main/NOTICE_aggregated

Re: Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

Looking in legal it seem the short vs long license hasn't been fully resolved and there's a few different views on it ie see [1] which has been reopened. However both Roy [1] [2] and the licence how to [3]  and this [4] say short licences / pointers are preferred.

The (short) discussion on legal around the Squiggly license hasn't brought up any objections to the current LICENSE and NOTICE and confirms that we shouldn't add anything to NOTICE. Although even that may also be considered unresolved [5], there seems to be mostly consensus on this [6]. I think some of the confusion here is that when you remove a copyright header from a file and replace it with an Apache one then you do need to add the copyright to the NOTICE file, and in some case people have added copyright notices to to NOTICE when the headers have remained the same, but that isn't legally required other than in a few rare cases. [6]

Current consensus is to a) use license pointers, b) keep licences as short, c) keep stuff out of NOTICE unless legally required (as it impacts downstream projects). a and b are optional ie you can still use the full licence if you want, but still meet the legal requirements. It's also clear than MIT/BSD (3 clause) licensed software do not need to be added to NOTICE [3] (even though some projects have done this).

The only legal JIRA I can find on aggregation is with open office and deals with the aggregation of LGPL dictionaries. [7] In the end they were allowed to included the LGPL dictionaries in their binary releases. They have chosen to use full licence text in their LICENSE file (2000 lines long!) [8] and have included more than what's the minimal legally required in their NOTICE [9]. But interestingly the dictionaries in questions are not even mentioned in LICENSE or NOTICE but instead are have short text without pointers in separate LICENSE [10] and NOTICE files [11]. This is a little different to our situation as it's for LGPL licence code which is normally not allowed to be included in Apache software.

I think the only conclusion is that there is not a single right way to do this and I think the best way forward to basically leave the license as it is (with some minor word changes suggested by Alex) until we find out otherwise and then change if needed. We are complying with the minimal legal requirements and currently practice (ie use license pointers and MIT/BSD don't modify NOTICE) but probably have a little more in LICENSE than the legal minimum but that's not a licensing error.

Thanks,
Justin

1. https://issues.apache.org/jira/browse/LEGAL-155
2. http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CCBFE3722-1B5C-48FC-AD82-0931EEC6F143@gbiv.com%3E
3. http://www.apache.org/dev/licensing-howto.html#permissive-deps
4. http://apache.org/dev/release.html#distributing-code-under-several-licenses
5. https://issues.apache.org/jira/browse/LEGAL-59
6. https://issues.apache.org/jira/browse/LEGAL-62
7. https://issues.apache.org/jira/browse/LEGAL-117
8. https://github.com/apache/openoffice/blob/trunk/main/LICENSE
9. https://github.com/apache/openoffice/blob/trunk/main/NOTICE
10. https://github.com/apache/openoffice/blob/trunk/main/LICENSE_aggregated
11. https://github.com/apache/openoffice/blob/trunk/main/NOTICE_aggregated

Re: Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Also, when you wanted to add copyright to LICENSE for Open-Sans font, the
> instructions from legal-discuss was to not do that.

Actually no - they said it was not part of the meeting the minimum legal requirements of something that was Apache licensed not MIT / BSD licenses. A very big difference.

In fact their advice was this:
"MIT and BSD are not ALv2. So, we need to take action to insure that the license for these bundled dependencies is handled properly. Thus we add their information to the LICENSE file. Also, MIT/BSD licenses are project/organization specific. The license and copyright/organization information are not separable."

Which is what I was following.

Justin

Re: Squiggly dictionaries license

[Alex Harui <ah...@adobe.com>]

On 9/5/14 6:47 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> I'll ask on legal-discuss
>
>Again IMO there no need to ask - all we have to do is comply with minimal
>legal requirements - which we certainly are. If we happen to do a little
>more than required that's not actually against the rules and in may
>actually be the right thing to do when we are using other people code. If
>we happen to get it wrong we can correct as needed when required in a
>future release. The whole point of being a TLP is we can make our own
>decisions, yes we may need advice on occasion but doesn't mean we have to
>go and ask legal every single time for every minor thing.
Apache loves to push decision making responsibility to the TLP, but
LICENSE and NOTICE seem to be an exception since the how-to says "if in
doubt, ask".  I think that's because there are legal implications and it
isn't so good, at least in the US, to take the "we'll fix it later"
approach.

Also, when you wanted to add copyright to LICENSE for Open-Sans font, the
instructions from legal-discuss was to not do that.

The worst that will happen is that legal-discuss will tell me it is a
minor thing and to go away or not answer at all.

-Alex

Re: Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I'll ask on legal-discuss

Again IMO there no need to ask - all we have to do is comply with minimal legal requirements - which we certainly are. If we happen to do a little more than required that's not actually against the rules and in may actually be the right thing to do when we are using other people code. If we happen to get it wrong we can correct as needed when required in a future release. The whole point of being a TLP is we can make our own decisions, yes we may need advice on occasion but doesn't mean we have to go and ask legal every single time for every minor thing.

Justin

Re: Squiggly dictionaries license

[Alex Harui <ah...@adobe.com>]

I'll ask on legal-discuss

On 9/4/14 11:52 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>> What do you think of the idea of not having the dictionaries in Git and
>> having the release packaging script get them?
>
>Means a release package script could be broken if the latest version
>don't work for some reason. I don't think it vital that users have the
>most up to date dictionaries. I'm sure you have a paper one on your
>shelf, do you buy a new one every year? But no objection if you add a
>target to get the latest.
>
>> 2) I would leave the names of the README file as it comes in the zip so
>> there is less chance for confusion as to who wrote that file.
>
>Fair enough.
>
>> The reason I think this is because [1] says "add a pointer to the
>> dependency's license within the source tree and a short note summarizing
>> its licensing", and the text attempts to follow the template given in
>>[1].
>
>The short license is optional so I took the middle ground, ie make it
>clear that they are copyright / licensed someone else by looking at the
>top level licence file, but not including the full READMEs. If people
>really want to know the full details they can look there.
>
>> I know later it says: "NOTE: It's also possible to include the text of
>>the
>> 3rd party license within the LICENSE file. This is best reserved for
>>short
>> licenses.", but IMO, the license is all of the licenses in the README,
>>not
>> just the "top-level" one for Kevin so I consider this a long license.
>
>Given Kevin's one is the license for the bundled bits, and then each bit
>has it own license, it made sense to me to include it in the top level.
>Given we're bundling his work I'm sure he would prefer if his name was
>mentioned at the top level, even if not doing so compiles with our
>minimum legal rules, he may think that we were not crediting him.
>
>Thanks,
>Justin

Re: Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> What do you think of the idea of not having the dictionaries in Git and
> having the release packaging script get them?

Means a release package script could be broken if the latest version don't work for some reason. I don't think it vital that users have the most up to date dictionaries. I'm sure you have a paper one on your shelf, do you buy a new one every year? But no objection if you add a target to get the latest.

> 2) I would leave the names of the README file as it comes in the zip so
> there is less chance for confusion as to who wrote that file.

Fair enough.

> The reason I think this is because [1] says "add a pointer to the
> dependency's license within the source tree and a short note summarizing
> its licensing", and the text attempts to follow the template given in [1].

The short license is optional so I took the middle ground, ie make it clear that they are copyright / licensed someone else by looking at the top level licence file, but not including the full READMEs. If people really want to know the full details they can look there.

> I know later it says: "NOTE: It's also possible to include the text of the
> 3rd party license within the LICENSE file. This is best reserved for short
> licenses.", but IMO, the license is all of the licenses in the README, not
> just the "top-level" one for Kevin so I consider this a long license.

Given Kevin's one is the license for the bundled bits, and then each bit has it own license, it made sense to me to include it in the top level. Given we're bundling his work I'm sure he would prefer if his name was mentioned at the top level, even if not doing so compiles with our minimum legal rules, he may think that we were not crediting him.

Thanks,
Justin

Re: Squiggly dictionaries license

[Alex Harui <ah...@adobe.com>]

On 9/4/14 3:35 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>I think providing one and pointing the user where they can get others or
>a newer one is best.
What do you think of the idea of not having the dictionaries in Git and
having the release packaging script get them?  That way the RM doesn't
have to remember to refresh the dictionaries before packaging the release.

Regarding the LICENSE, my reading of [1] makes me think the right answer
would be:

1) In LICENSE, the only text other than the Apache License would read:

This product bundles the SCOWL (and friends) Hunspell dictionaries for
en_US and en_CA, which is available under a
"BSD/MIT-like" license.  For details, see
dictionaries/en_US/README_en_US.txt and/or
dictionaries/en_GB/README_en_GB.txt.


2) I would leave the names of the README file as it comes in the zip so
there is less chance for confusion as to who wrote that file.

The reason I think this is because [1] says "add a pointer to the
dependency's license within the source tree and a short note summarizing
its licensing", and the text attempts to follow the template given in [1].

I know later it says: "NOTE: It's also possible to include the text of the
3rd party license within the LICENSE file. This is best reserved for short
licenses.", but IMO, the license is all of the licenses in the README, not
just the "top-level" one for Kevin so I consider this a long license.

And, of course, as [1] says, if there is doubt, we should ask on
legal-discuss.

Thoughts?
-Alex

[1] http://www.apache.org/dev/licensing-howto.html

Re: Squiggly dictionaries license

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I looked at the commits.  I'll have to go digging through the policy docs
> to make sure it is right.  I would have done it differently but I could
> certainly be wrong.

OK.

> Before I go digging, though, do we know how often the dictionaries get
> updated?

As a guess every 3 -6 months [1]

> Do we want to check one into Git if they do change?  Do we want to
> download one when building a release binary if it can get stale?

I think providing one and pointing the user where they can get others or a newer one is best. While bundling adds to LICENSE you don't get any download issues.  Not everyone knows how to (or has permission to) run ant, is always connected 100% of the time with reliable internet, and as we know some countries block sites.
 
> Or should we just provide an Ant target or mini-install so they can get the
> latest and tell folks how to do that in the README?

May be able to do that as well.

Thanks,
Justin

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

Re: Squiggly dictionaries license

[Alex Harui <ah...@adobe.com>]

I looked at the commits.  I'll have to go digging through the policy docs
to make sure it is right.  I would have done it differently but I could
certainly be wrong.

Before I go digging, though, do we know how often the dictionaries get
updated?  Even the "real world" dictionaries get updated with new words.
Do we want to check one into Git if they do change?  Do we want to
download one when building a release binary if it can get stale?  Or
should we just provide an Ant target or mini-install so they can get the
latest and tell folks how to do that in the README?  I get that it could
save you a step, but doesn't if you end up having to go check if you have
the latest.

-Alex

On 9/4/14 1:41 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:

>Hi,
>
>I just added some MIT / BSD dictionaries to Squiggly and modified the
>LICENSE in what I think is is accordance with their license. Any
>objections to what I've done here before we (eventually in a month or so)
>come around to making a new release.
>
>https://github.com/apache/flex-utilities/blob/develop/Squiggly/LICENSE
>
>Thanks,
>Justin