Revert "Close #628. Switch to text-unidecode"

[jorti]

This reverts commit e32a0cd.

What does this changes

Reverts the the use of text-unidecode to unidecode

What was wrong

text-unidecode is under Artistic license which is not FOSS compatible

How this fixes it

This change reverts the commit that changes to text-unidecode

Fixes #727

[fcurella]

Hi @jorti

we used to use unidecode, but we had to switch precisely because it's GPL and that was too restrictive (see #628).

Could you provide any documentation to your statement the the artistic license is not FOSS compatible? I see the artistic license listed as approved on opensource.org

[jorti]

I'm the Fedora packager of faker and the artistic license is forbidden by the Fedora policy:

https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses

More info:

http://www.gnu.org/licenses/license-list.html#ArtisticLicense

[fcurella]

If I'm understanding this correctly, text-unidecode is under Artistic License v1, which is not OK with Fedora, while Artistic Clarified or Artistic v2 would be. Is that a correct interpretation?

Ultimately, the issue is that we don't want unidecode because it's GPL, and we don't want text-unicode because it's not FSF approved.

Looks like text-unidecode is in the process of changing their license (see kmike/text-unidecode#9 - last updated 10 days ago). Maybe you can help them out?

[tbrlpld]

@fcurella Yes, looks like they clarified the license which is now Artistic 1.0 or GPL 2+.

So now it would fail both the requirements stated above. It is now GPL and not FSF approved.

[kmike]

@tbrlpld Perl license (dual Artistic and GPL) should be fine for Fedora: https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses, this is exactly a license text-unidecode is using.

[tbrlpld]

@kmike How does one decide which of the two licenses applies? There seems to be different understanding between Perl and GNU if linking to the library (i.e. import in Python) creates the requirement to make the linking application/library also GPL.

Furthermore, any object code linked with perl does not automatically fall under the terms of the GPL, provided such object code only adds definitions of subroutines and variables, and does not otherwise impair the resulting interpreter from executing any standard Perl script. I consider linking in C subroutines in this manner to be the moral equivalent of defining subroutines in the Perl language itself.

-- https://dev.perl.org/licenses/

This is similar to what the Artistic License is stating.

6. The scripts and library files supplied as input to or produced as
   output from the programs of this Package do not automatically fall
   under the copyright of this Package, but belong to whoever generated
   them, and may be sold commercially, and may be aggregated with this
   Package. If such scripts or library files are aggregated with this
   Package via the so-called "undump" or "unexec" methods of producing a
   binary executable image, then distribution of such an image shall
   neither be construed as a distribution of this Package nor shall it
   fall under the restrictions of Paragraphs 3 and 4, provided that you do
   not represent such an executable image as a Standard Version of this
   Package.

7. C subroutines (or comparably compiled subroutines in other
   languages) supplied by you and linked into this Package in order to
   emulate subroutines and variables of the language defined by this
   Package shall not be considered part of this Package, but are the
   equivalent of input as in Paragraph 6, provided these subroutines do
   not change the language in any way that would cause it to fail the
   regression tests for the language.

-- https://dev.perl.org/licenses/artistic.html

But, this seems to be conflicting with how the FSF interprets GPL:

It has always been the FSF’s position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed as a whole under the terms of the GPL, an effect which can be described as “hereditary.” So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL.
-- https://www.gnu.org/licenses/lgpl-java.html

So if I an application/library links to text-unidecode does it need to be GPL itself or not?

[fcurella]

@jorti Can you confirm if GPLv2 + Artistic V1 works for Fedora?

[kmike]

These are good questions @tbrlpld.

My feeling is that the licenses may work out ok. Fedora prohibits packaging Artistic 1.0-only packages as they're not considered free - but Perl license it not prohibited, as users of the package can use GPL terms if they want. python-faker also can use text-unidecode, even in Fedora, as using an Artistic-licensed or Perl-licensed package doesn't put restrictions on python-faker, according to the license terms. I don't see a conflict here. Having text-unidecode in Fedora doesn't change text-unidecode license to GPL, the license is still a dual license, even if text-unidecode is executed under Fedora.

There must be zillions of Perl modules packaged for Fedora, with a different mixes of licenses, there could be similar cases to look at.

Sorry, I won't be able to participate in deeper license discussions, it is such a rabbit hole, and I have neither knowledge nor time to get this knowledge :)

And anyways, I can't change text-unidecode license, because the license is inherited, it was not my decision to use it.

[tbrlpld]

@kmike Haha, yea I know what you are talking about. It is a rabbit hole, and I have fallen in I am afraid...

Regarding you being forced to keep the Perl dual license model, this article would suggest otherwise:

In 1991, Wall carried out what he later called a“cultural hack”(quoted in Tamiya, 2001), inventing the dual license by releasing Perl under both the GPL and The ArtisticLicense. The latter was authored by Wall, and distinguished itself from the GPL in two important ways. First, it laid out a number of provisions to ensure the relative integrity of Perl, allowing modifications and reuse but maintaining“some semblance of artistic control”over“the standard distribution”(Wall,1991, emphasis in original). Second, it made explicit that Perl could be used to create commercial products that could be released as proprietary software.

The Artistic License thus emphasized authorship and control at the same time that it was more permissive than the GPL. If the GPL enforces a form of solidarity in which any modifications or extensions are returned to the commons, the Artistic License seeks to maintain Perl’s integrity and Wall’s reputation while simultaneously allowing for commercial use. The fact that users could choose which license they wanted to use Perl under was itself innovative. Rather than remove the GPL and risk alienating the free software community, Wall’s solution meant having it both ways: Perl belonged to the collective and to the author; it was an expression of GNU solidarity while also a tool for commercial software production.
— Full article: Having it both ways: Larry Wall, Perl and the technology and culture of the early web

The fact that your dependency it is dual licensed with GPL OR Artistic should mean that you as the "user" can choose to use the dependency under the Artistic license which does not impose the limitation to reuse the same license.

a) the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version, or

b) the "Artistic License".
-- https://dev.perl.org/licenses/

But I guess the same would then count for Faker since you are licensing with GPL OR Artistic as well would give Faker the freedom to use text-unidecode under the Artistic license. Fedora on the other hand can choose to look at text-unidecode as being GPL licensed which fulfills their requirement for a "good license".

Sorry for ranting. I guess I am more talking to myself than anything.

Just to clarify for myself: if I depend on Faker (which pulls in text-unidecode) I am a user of text-unidecode and I can choose to use text-unidecode under the Artistic license. I guess...

[fcurella]

The only thing that really matters for the purpose of this issue is if the original author (@jorti ) is OK with the new license.

[jorti]

@jorti Can you confirm if GPLv2 + Artistic V1 works for Fedora?

Yes, the new dual licensing of text-unidecode allows us to choose GPLv2+. This is the same case as Perl, so there's no problem now.

Thank you.

[fcurella]

Thank you @jorti ! That's all we need! :)