[
https://issues.apache.org/jira/browse/PDFBOX-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146651#comment-14146651
]
John Hewson edited comment on PDFBOX-2380 at 9/24/14 6:15 PM:
--------------------------------------------------------------
The license says "with or without modification", so there are no issues with
modification, this is something which has changed vs. the old glyph list
license.
I agree it looks like a 3-clause BSD, which is category A, in the discussion
from LEGAL-185, it is the 4-clause BSD which is problematic, as it includes the
"advertising clause", namely:
{quote}
4. Neither the name of the <organization> nor the names of its contributors may
be used to endorse or promote products derived from this software without
specific prior written permission.
{quote}
Which is not present in this license. The information on the licensing page may
or may not be out of date regarding the 4-clause BSD, but the phrase "BSD
(without advertising clause)" covers BSD-3 already, because it has no licensing
clause.
It might still be worth asking legal@ to make this explicit on the page, but as
it stands we're ok with the BSD-3.
was (Author: jahewson):
The license says "with or without modification", so there are no issues with
modification, this is something which has changed vs. the old glyph list
license.
I agree it looks like a 3-clause BSD, which is actually allowed, in the
discussion from LEGAL-185, it is the 4-clause BSD which is problematic, as it
includes the "advertising clause", namely:
{quote}
4. Neither the name of the <organization> nor the names of its contributors may
be used to endorse or promote products derived from this software without
specific prior written permission.
{quote}
Which is not present in this license. The information on the licensing page may
or may not be out of date regarding the 4-clause BSD, but the phrase "BSD
(without advertising clause)" covers BSD-3 already, because it has no licensing
clause.
It might still be worth asking legal@ to make this explicit on the page, but as
it stands we're ok with the BSD-3.
> Glyphlist .properties are not ordered
> -------------------------------------
>
> Key: PDFBOX-2380
> URL: https://issues.apache.org/jira/browse/PDFBOX-2380
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: John Hewson
> Assignee: John Hewson
>
> Currently we use .properties files to load the glyph lists, however Java's
> Properties is not ordered (the properties are stored in a Hashtable) and so
> the glyphs are not read in the correct order.
> This results in incorrect encoding when calling GlyphList.unicodeToName(),
> because the Adobe glyph lists are ordered: the default mapping comes first,
> and auxiliary mappings follow it, for example:
> {code}
> space=0020
> spacehackarabic=0020
> {code}
> Currently in PDFBox, GlyphList.unicodeToName(0x20) returns "spacehackarabic",
> which is wrong, we always want the first entry in the glyph list.
> We need to move away from using .properties and instead just use Adobe's
> existing glyph list format, the only difference is that we switch {{=}} for
> {{;}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
