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 alr

      • 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 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.

        The question is, does licensing code under terms other than Perl’s offer any tangible benefits? So far, the thrust in that direction seems to be philosophically argued – as in the debate over the necessity of copyleft, say. (I think this is what you were trying to make a case about in your muddled response, but I could not extract the argument proper from it.) And the pragmatist in me finds that unsatisfactory.

        After all, we are all hackers and none of us likes to deal with licences (though some less so than others). I see the value in standardising on a choice, even if it’s merely a suboptimal compromise, purely for the benefit of minimising the amount of licensing related minutiæ that a user will have to deal with.

        • 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.