Re: Marpa::R3, Perl license

2016-05-03 Thread Ron Savage
Check your LICENSE files - FSF has a new physical address: Copyright (C) 1989, 1991 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from t

Re: Marpa::R3, Perl license

2016-05-03 Thread Jeffrey Kegler
The difference seems to be between what are called "permissive" licenses and copyleft licenses. Perl license is a dual-license, and the licensee gets the choice. The artistic license 1.0 seems to be accepted as permissive. This "Perl license" is by far the most used license on CPAN, and nobody s

Re: Marpa::R3, Perl license

2016-05-03 Thread Ed Avis
Jeffrey Kegler writes: >Under the LGPL, there were cases where the company lawyers told people they >could not read my code. Have you checked that GPL+Artistic would fix this? I would imagine that the same lawyers would give the same answer. -- Ed Avis -- You received this message because

Re: Marpa::R3, Perl license

2016-04-26 Thread Jeffrey Kegler
That's an interesting idea, but I think I want to go with the community consensus. Nobody seems to express a problem with the Perl dual-license not being liberal enough. The Perl Foundation's licensing advice centers on it. And even the FSF, for Perl modules, suggests that following the Perl com

Re: Marpa::R3, Perl license

2016-04-26 Thread Ed Avis
If you want to make the licence strictly more liberal than before, you could make it 'LGPL or Artistic' rather than 'GPL or Artistic'. -- Ed Avis -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receivin

Marpa::R3, Perl license

2016-04-21 Thread Jeffrey Kegler
The folks on the marpa IRC channel and I have quietly begun a Marpa::R3 effort. This will eliminated everything kept in Marpa::R2 for backward compatibility: The only supported interface will be the SLIF (which is the one almost everyone uses anyway). This will clear the way to a refactoring of