Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Module authors should license their code “under the same terms as Perl $VERSION” rather than the common default of “under the same terms as Perl”. Note the presence of a specific version. This addresses the ambiguity problem.

    Licensing the code differently offers no benefit and should be discouraged, even though other licences may be better than the dual licence along various axes.

    Why?

    Because the licence of Perl itself is not going to change any time soon, and any user who uses

    • Hi Aristotle!

      Interesting point, but I still disagree. I think you're making here a fallacy, which is of more general nature, but I'll focus on our example. First of all, sometimes Perl code can prove useful without the perl implementation itself. Often it can be converted to python, Ruby, C, Java or a different language directly, often by copying and pasting code and then modifying it. To say nothing of automated Perl-to-Perl6/python/etc. converters like the one Larry Wall started writing. (He has already implemented a way to dump the syntactic structure of perl5 code into XML/YAML.)

      But even if that's not the case and the code will remain Perl and run with perl5, then there is a difference. Let's take my LM-Solve (a solver for some puzzle games, commonly known as Logic Mazes, that are easy to solve with a computer), which is written in Perl and licensed under the MIT X11. Now let's suppose Microsoft takes my LM-Solve, forks it, adapts it to solve all Solitaire card games, Sudoku, Nurikabe, and Kakuro, adds a GUI, makes it 1,000 times faster, all while keeping it written in Perl 5 and running under perl 5. Then they release it as a commercial, proprietary product called Microsoft Logic Mazes Solver Enterprise Edition XP .NET Pro. They still respect the licence of perl 5 and distribute all the source code on their package. However, the LM-Solver-derived code and a lot of code that was added is now no longer free.

      That's OK by me, because I've given them permission to do so by licensing LM-Solve under the MIT X11 licence. An attribution somewhere would be nice of course, but not absolutely necessary [gnu.org]. (They do give credit to Eric S. Raymond among others).

      So now if I wish to catch with the Microsoft product, I'll need to implement this functionality myself. Again, it's OK. However, if I licensed it as same terms as perl 5, then from my understanding, I still could use all of my original code.

      It sometimes makes sense to make something more permissive (or more restrictive) than the implementation's licence. You wouldn't expect an open-source .NET software to carry the Microsoft .NET EULA, do you? (And there are plenty of FOSS .NET software, and some of it still has problems running on Mono). And if you write a Perl program that uses Oracle and runs on Apache's mod_perl, which licence do you use? ;-)

      Many (all?) of the "BBC" modules on CPAN are released under the GPL exclusively. I don't think you can get a commercial licence for these modules from the BBC, though you may be able to get an exemption from the GPL in certain cases. Again, we can assume they didn't like the Artistic licence enough and preferred the GPL exclusively. Don't like it - re-implement it or try to convince them to use a more permissive licence.

      So it's not that simple as just saying that it should be under the same terms as perl-5.10.0 or whatever. You can often find code modules under different GPL compatible licences in GNU or otherwise GPLed software, and it was not converted to the GPL. That's because the software as a whole is GPLed, and it doesn't matter that an isolated part is not.

      • OK, but… what is your point? You tried to give an example… I think it kinda fizzled out at the end? I cannot make a coherent argument for anything in particular from what you are saying.

        My point is pretty simple: that users in companies with legal departments are likely to have a list of approved licences for free software, and that using software provided under a licence that is not on that list will require a lengthy process of evaluation, and that in such a company, if Perl is in use, then

        • Hi Aristotle!

          Sorry for the late response.

          OK, but… what is your point? You tried to give an example… I think it kinda fizzled out at the end? I cannot make a coherent argument for anything in particular from what you are saying.

          What I meant to say was that they can take my code, modify it and sublicence it under a different (possibly proprietary licence). Against, most programs on Linux use the LGPLed glibc, which does not allow that, but as a whole proprietary code on Linux is possible. And you can sublicence X-Windows, XLib, or different BSD licences.

          My point is pretty simple: that users in companies with legal departments are likely to have a list of approved licences for free software, and that using software provided under a licence that is not on that list will require a lengthy process of evaluation, and that in such a company, if Perl is in use, then the dual licence is necessarily already on the list of approved licences. So any module deviating from the Perl dual licence will be disadvantaged because developers looking for code to solve some problem are likely to take some other module or even just roll their own before they go through the bureaucracy of getting a new licence approved.

          So far this is all but fact, not opinion, and therefore not subject to dis-/agreement.

          You may dispute the import of this situation, saying that it is too rare among all the users of your code to care about. Maybe you want to claim that the MIT licence is widespread enough that it will be part of any list of approved licences sooner or later.

          But it’s fact that by licensing code under terms other than those of Perl, you create a real potential to inconvenience some users.

          I see. Well, first of all let me say that I am not against big business. (I'm not pro-it either). However, I believe that stu

          • Replying to myself, I'd like to note that often small companies are also stupid in many respects, which is part of the reason why most Startups fail. But it's probably true, that so far the more a company grew, the more procedures it acquired, and the less agile it has become. As opposed to Paul Graham, I do not rule out the possibility of a large but agile and efficient company, but I'm not sure if it has happened yet.