www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LEGAL-64) Artistic License 1.0 licensed "data" in ASF repo as testing resources
Date Sat, 19 Dec 2009 06:53:18 GMT

    [ https://issues.apache.org/jira/browse/LEGAL-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792798#action_12792798
] 

Henri Yandell commented on LEGAL-64:
------------------------------------

Apologies for this issue not having been replied to.

Perl licensing is at http://dev.perl.org/licenses/ - namely Perl is dual licensed under GPL
v1+, or Artistic License (of which there a few versions, 1, 1-perl, 1-clarified and 2....
this appears to unsurprisingly be 1-perl). 

Oddly, we don't appear to have yet looked at the artistic license. Looking at the Perl Artistic
License (what I call 1-perl above) clauses:

1. Attribution clause. Fine.
2. Patches clause. Interesting, but not a big deal.
3. Source distribution/modification clause - notice required in source and restriction on
distribution which make this a weak copyleft license. 
4. Binary distribution clause - not applicable in this case, or in most cases of the license
(CPAN packages).
5. Not claiming product as your own/charging for the software clause. Not a big deal. 
6. Not copyleft to input/output clause. Unnecessary clause imo.
7. Not copyleft to perl/C that links to this. Wonderful - language specific item.
8. Do not endorse clause. Not a big deal.
9. NO WARRANTY clause. Fine.

So interesting items:

Clause 3a contains weak copyleft. From our direct point of view not a problem - releasing
our changes under AL 2.0 would satisfy this, however our users do not expect to see such restrictions
on our software. This would usually make this category B (binary only). Clause 3b is a non-event,
as is 3d; however 3c is so Perl specific as to make the Artistic License 1.0 into a permissive
and not weak-copyleft license. Fine... test data, we will "remove any non-standard executables"...
which is none.

I'm very interested in others opinions on 3a vs 3c. I'll also check various texts on Monday
(I keep them at work) to see if they discuss this.

Clause 7 looks like weak copyleft, but the only copyleft clause being weakened is for object
code or executables. Does it make a difference that we are in Java? I don't think so. Again
I'll check texts in case it's discussed, but my read on this is that a) it would be fine to
infer this means other languages and b) it's a no-op clause anyway as the only item is not
relevant to the use case.

I think this is okay as a Category A license ('like Apache'), but it would be closest license
in there to Category B ('binary only'). Possibly it's Category A but not for Object code or
Executables; which is barely going to affect us.

Let's see what others say.

> Artistic License 1.0 licensed "data" in ASF repo as testing resources
> ---------------------------------------------------------------------
>
>                 Key: LEGAL-64
>                 URL: https://issues.apache.org/jira/browse/LEGAL-64
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Stefano Bagnara
>
> I wrote a DKIM library (email authentication) in Java for the James
> project. Now I was expanding the test cases and found that the perl
> library named "Mail-DKIM" includes a good corpus of signed messages
> (http://search.cpan.org/dist/Mail-DKIM/). I'd like to add them "as is"
> in our test/resources folder so that they can be processed by a java
> tester class as part of the default tests.
> The library itself claims the license is the same of Perl 5.8.6, so it
> is the Artistic License 1.0:
> http://www.opensource.org/licenses/artistic-license-1.0.php
> From my understanding there should be no harm in redistributing this
> kind of "data" (they are email messages, mime messages, and not some
> language code) in apache packages, but I didn't find a clear answer on
> the website.
> So:
> 1) Are we allowed to include them in our src/test/resources folder
> (and in derivate distributed packages)?
> 2) If "yes": where am I supposed to write their "origin"/"license"?
> (NOTICE/LICENSE/README? In the root of cvs or the src/test/resources
> folder where I'll copy them?).
> PS: I open this jira issue because it seems my messages do not pass through the legal-discuss
list anymore (investigating on this).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message