On Thu, Jul 17, 2014 at 10:09 AM, Nick Wellnhofer <[email protected]> wrote:
>> Do we need some clarification on this from Apache legal? Or has it >> been clarified before and I'm just missing it? > > AFAIK, this is still unresolved. See > > https://issues.apache.org/jira/browse/LEGAL-86 It seems likely that if we press the issue with Apache Legal Affairs, Artistic 2.0 would get added to "Category B" list. Artistic 2.0 is similar to the Mozilla and Eclipse licenses: copyleft, but with reciprocity scoped to the "work" (as opposed to scoped to the "derivative work" as with GPL). Approval is not a sure thing because LGPL also fits into that category but is disallowed because of some specific provisions. But let's cross that bridge when we come to it -- first we'd have to determine that we want to add Sereal as a dependency over other competitors such as Apache Avro. Personally, I'm not rushing to swap out Storable for anything because Storable is in the Perl core and the present implementation is at least functional. You may have seen some churn in recent commits regarding Storable, but that was unrelated. The issue those commits deal with is that without custom STORABLE_freeze and STORABLE_thaw hooks, round-tripping any Clownfish-based Perl object through Storable will eventually result in a segfault -- so we make sure that the we have default hooks installed which throw sensible exceptions instead. The reason the segfault gets triggered is that Clownfish objects are represented in Perl as scalar refs with the scalar holding a the memory address of a Clownfish object -- and when a new object is reconstituted by Storable's thaw(), that fresh scalar will no longer be holding a reference to a real Clownfish object at that memory address. Later, when the Storable-created Perl object gets destroyed, attempting to call the Clownfish-space Destroy() method on that invalid pointer causes a segfault. Marvin Humphrey
