Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • Well, the terms of Perl itself include the "or (at your option) any later version" clause.
    I have no idea what Linus means, as I don't follow that discussion, but I do interpret the phrase in Perl's license as "whatever changes in Perl's license, you're free to choose the version you like best".

    So it's impossible to get worse for you.
    • Except the "you" who is free to choose is the user, not the author.
      • Well, that's what I meant. Wasn't that clear?

        What I ment was that you as a user are free to upgrade any module you used before because the license that it comes under can't ever get worse for you, as you're free to choose which one applies.
        • My appologies. What I was trying to say is that the user might be free to choose a license I disagree with (how would I know, I'm giving them the right to choose anything the FSF ever calls the GPL).
  • Choosing a license depends on what you want to do and what you want to control. You haven't said anything about that.

    My goal for my publicly available code is that people can use it. Putting "under the same terms as Perl itself" seems to accomplish that goal, and I don't think about it any further.

    Some people like to go on and on about licenses, but I tend to think it's mostly just shifting the bits around with providing any more real benefit to the world. I just want people to be able to use my code. I'm n
    • Right.

      My primary goal is to make a contribution. That means that I want people to be able to use, learn from, contribute to, and improve on my code.

      That said, I'm not particularly happy on giving somebody the right to license my code under terms I haven't even read because they don't exist yet.
    • And this isn't a question about which license I should use. I wouldn't be asking that on use.perl. I simply want to know how a particular choice of license would affect others.
      • Some concerns:

        If you plan on having your code go into core, then providing it under a licence different from that of Perl is going to be a serious issue.

        If you want to avoid burdening commercial users of your code, you should stay close to the pack, because some of them will have to have everything vetted by the legal dept. before they can use it. The less new text you introduce, the more likely that will succeed.

        • If I were to write anything that was considered for inclusion into the core, I would be happy to relicense it under "the same terms as Perl itself". Most modules IIRC don't go into core without other revamping as well, so it would be the perfect opportunity for a relicense.

          The "avoid burdening users" thing is exactly what I'm trying to figure out. Commercial users have to get everything vetted by their legal department, but a ton of people don't even have a legal department to check things with. I'm trying
  • I stick with "same as Perl itself".

    If in future the terms of Perl go out of sync with the GPL or something, we're all fucked anyway, so I figure that will not happen.

    At the end of the day, you are giving away code. It's a gift.

    Personally, I'm pretty cool with whatever people do with my code. I release it because it makes me write functionality better and more strictly on myself, I get better testing, and a range of other benefits.

    While I might object a little if someone took some of my stuff and did somethi