[lucy-dev] Sereal

[Peter Karman <pe...@peknet.com>]

https://github.com/Sereal/Sereal

Was looking recently at the Storable-based LucyX::Remote stuff and it occurs to
me this might be a substitute serialization format.

-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [lucy-dev] Sereal

[Nick Wellnhofer <we...@aevum.de>]

On 18/07/2014 09:44, Moritz Lenz wrote:
> (But I do have to wonder, why is it OK to use perl, but it wouldn't be OK to
> use a perl library under the same license? That does seem a tad odd to me).

This has been discussed at length on lucy-private when Lucy was still in the 
incubator. Here's my interpretation of the results of this discussion:

Regarding the GPL, the Perl license terms make it clear that Perl modules and 
scripts are not considered to be a derivative work of the Perl interpreter and 
do not fall under the same licensing terms. The same goes for XS bindings:

https://issues.apache.org/jira/browse/LEGAL-79

For a Perl library, it's not that clear. A project using that library might be 
considered derivative work. This rules out the GPL option, at least if you 
take a conservative approach.

This leaves the option of choosing the Artistic license. It is unclear whether 
it would be OK to bundle such libraries with Lucy (LEGAL-86). But using them 
as a system requirement shouldn't be a problem, IMO.

So I want to retract my statement that Perl-licensed libraries are "unusable" 
for Lucy. Still, the Lucy developers went great lengths to remove all 
dependencies on CPAN modules. When choosing a serialization library, a 
permissive license would be a big plus.

Nick

Re: [lucy-dev] Sereal

[Peter Karman <pe...@peknet.com>]

Moritz Lenz wrote on 7/18/14 3:44 AM:

> You could just ask the developers nicely if they'd re-release it under the
> Apache license, or something explicitly compatible with it.
> 
> Licensing under "the same terms as Perl itself" is pretty much the default in
> the Perl community, in particular if the authors don't care much about the license.

I have done so.

https://groups.google.com/forum/#!topic/sereal-dev/iTwmAnDDVsA


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [lucy-dev] Sereal

[Moritz Lenz <mo...@faui2k3.org>]

Hi all,

On 07/17/2014 05:39 PM, Nick Wellnhofer wrote:
> On 17/07/2014 16:12, Peter Karman wrote:
>> https://github.com/Sereal/Sereal
>>
>> Was looking recently at the Storable-based LucyX::Remote stuff and it
>> occurs to
>> me this might be a substitute serialization format.
>
> The source code doesn't come with a license but according to this blog
> entry and Makefile.PL, it seems that the authors intended to release
> under the Perl license (Artistic and GPL):
>
> http://blog.booking.com/sereal-a-binary-data-serialization-format.html
>
> This would make it unusable for us.

You could just ask the developers nicely if they'd re-release it under 
the Apache license, or something explicitly compatible with it.

Licensing under "the same terms as Perl itself" is pretty much the 
default in the Perl community, in particular if the authors don't care 
much about the license.

(But I do have to wonder, why is it OK to use perl, but it wouldn't be 
OK to use a perl library under the same license? That does seem a tad 
odd to me).

Cheers,
Moritz

Re: [lucy-dev] Sereal

[Marvin Humphrey <ma...@rectangular.com>]

On Thu, Jul 17, 2014 at 10:09 AM, Nick Wellnhofer <we...@aevum.de> 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

Re: [lucy-dev] Sereal

[Nick Wellnhofer <we...@aevum.de>]

On Jul 17, 2014, at 18:06 , Peter Karman <pe...@peknet.com> wrote:

> Artistic 2.0 license is explicitly compatible with Apache license.

Yes, but Perl 5 projects are typically released under Artistic 1.0.

> 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

Nick

Re: [lucy-dev] Sereal

[Peter Karman <pe...@peknet.com>]

Nick Wellnhofer wrote on 7/17/14 11:39 AM:
> On 17/07/2014 16:12, Peter Karman wrote:
>> https://github.com/Sereal/Sereal
>>
>> Was looking recently at the Storable-based LucyX::Remote stuff and it occurs to
>> me this might be a substitute serialization format.
> 
> The source code doesn't come with a license but according to this blog entry and
> Makefile.PL, it seems that the authors intended to release under the Perl
> license (Artistic and GPL):
> 
> http://blog.booking.com/sereal-a-binary-data-serialization-format.html
> 
> This would make it unusable for us.


Artistic 2.0 license is explicitly compatible with Apache license.

"Section 4(c)(ii) is what we call the "relicensing" clause. Perl 6 and Parrot
won't be dual licensed with the GPL, unlike Perl 5. Since they won't be dual
licensed, if you want to use Perl 6 or Parrot under a GPL license, you will
doing so under 4(c)(ii). Several other open source and free software licenses
also qualify under 4(c)(ii), including the LGPL, MPL, and the Apache license.
Note that these are only what have become known as "copyleft" licenses: "freely
available" means both free as in speech and free as in beer."

http://www.perlfoundation.org/artistic_2_0_notes

Do we need some clarification on this from Apache legal? Or has it been
clarified before and I'm just missing it?

-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [lucy-dev] Sereal

[Nick Wellnhofer <we...@aevum.de>]

On 17/07/2014 16:12, Peter Karman wrote:
> https://github.com/Sereal/Sereal
>
> Was looking recently at the Storable-based LucyX::Remote stuff and it occurs to
> me this might be a substitute serialization format.

The source code doesn't come with a license but according to this blog entry 
and Makefile.PL, it seems that the authors intended to release under the Perl 
license (Artistic and GPL):

http://blog.booking.com/sereal-a-binary-data-serialization-format.html

This would make it unusable for us.

Nick