Change to Artistic License 2.0

[jmm]

I just noticed that the license was recently changed to "Artistic-2.0". I'm not too familiar with that license, and it's a hell of a lot more to digest than MIT or Simplified BSD, so before I do that can you please comment on the reasons for adopting this license?

[joeybaker]

Sure thing. I'm trying to get all my projects on the Artistic License because it's a little bit more restrictive than MIT. http://choosealicense.com/licenses/ has a good description:

the Artistic license requires that modified versions of the software do not prevent users from running the standard version.

As compared to MIT, I like that it requires that forks list significant changes from the original (that's just common courtesy).

[jmm]

What does that quote mean? What's a practical example?

As compared to MIT, I like that it requires that forks list significant changes from the original (that's just common courtesy).

Can you please elaborate on this...what makes it important / valuable / necessary as a term of the license?

[joeybaker]

If you decide to fork remapify and run it as a separate project (e.g. without the intention of merging it back), this license requires that you list the differences between your fork and the original.

[joeybaker]

I'm happy to talk this through, but I'm just wondering – do you have a specific concern? The Artistic license is actually pretty common, for example, it's the license that npm uses: https://github.com/npm/npm/blob/6f2b726c03bab3eb45c1f277fd929cdacd9d6323/package.json#L182

[jmm]

It may be common, I can only say for certain that it's not common in my experience (and I've never contributed code to npm), and the OSI lists it in the category of "Other/Miscellaneous licenses" rather than "Licenses that are popular and widely used or with strong communities".

do you have a specific concern?

Just the usual concerns that open source users / contributors generally have with licenses, especially unfamiliar ones.

If you decide to fork remapify and run it as a separate project (e.g. without the intention of merging it back), this license requires that you list the differences between your fork and the original.

I understood the meaning of that, although I'm not sure I get the importance of it in choosing what license to use. Like, what's an example of the value of that over diffing the code?

I think I was unclear in my question. I meant what is the meaning and practical example of this passage that you quoted:

the Artistic license requires that modified versions of the software do not prevent users from running the standard version.

[joeybaker]

Ah! Sorry, that quote is confusing. I think it's basically trying to point out that if you fork, without the intention of sending a PR you must not prevent the original from running, or in plain english: pick a different name for the project.

I'm not a lawyer, but I'll try to be more clear. The benefits of the Artistic License over MIT, as I understand it, are that if you fork, without the intention of contributing back to the project, you must:

1. pick a new name for your project so that people don't get confused with many different projects all claiming to be the same thing, but actually offering different features.
2. document how your new project is different from the original so that people can intelligently choose which to use.

Does that answer it for you?

[jmm]

That tells me what you interpret the differences and benefits to be, which is what I was asking. My initial impression is that these differences are of limited / questionable value and any possible benefit to them may be outweighed by the drawbacks of using a less mainstream license that is far more complex. Some of these concerns are addressed in other ways in practice (perhaps more effectively than a license clause would achieve them) by things like NPM package naming and GitHub repo URLs.

I'm not so sure this says what you think it says with regard to that anyway (now that I'm actually getting sucked into reading it). These are excerpts from the license, with parts elided:

Distribution of Modified Versions of the Package as Source
(4) You may Distribute your Modified Version as Source...provided that you do at least ONE of the following:

(a) make the Modified Version available to the Copyright Holder of the Standard Version...
(b) ensure that installation of your Modified Version does not prevent the user installing or running the Standard Version. In addition, the Modified Version must bear a name that is different from the name of the Standard Version.
(c) allow anyone who receives a copy of the Modified Version to make the Source form of the Modified Version available to others...

According to this could I not fork it on GitHub, keep the name, "prevent users from running the standard version" and still be in compliance with the license because of satisfying a because the modified version is available to you?

As an aside, is this connected in any way with the issues that are being discussed on io.js or just a coincidence?

[joeybaker]

I'm not a lawyer, but yes, it appears you're right: you can get away without renaming if you make the modified version available and document the changes. That is an important distinction over MIT.

Here's another summary site thought, that marks renaming as a MUST. https://tldrlegal.com/license/artistic-license-2.0-%28artistic%29

I like the artistic license because I believe it protects open source software more than MIT. I'm not sure that you're arguing against the Artistic 2.0 license, but if you are, the only argument I've heard against is that MIT is more common. That doesn't hold much weight for me because 1) the Artistic License is still quite common, 2) it's similar enough to MIT that it shouldn't cause anyone willing to use MIT software any troubles other than forcing them to be good OSS citizens.

Regarding your aside: No, this is not in anyway connected to io.js.

[jmm]

I'm not a lawyer, but yes, it appears you're right: you can get away without renaming if you make the modified version available and document the changes. That is an important distinction over MIT.

The important distinction is the requirement to document the changes? I'm skeptical of the value of that, and it seems like a very subjective standard anyway.

Here's another summary site thought, that marks renaming as a MUST.

Based on what?

I like the artistic license because I believe it protects open source software more than MIT.

In what way? Reduced likelihood of confusion?

I like the artistic license because I believe it protects open source software more than MIT. I'm not sure that you're arguing against the Artistic 2.0 license, but if you are, the only argument I've heard against is that MIT is more common. That doesn't hold much weight for me because 1) the Artistic License is still quite common, 2) it's similar enough to MIT that it shouldn't cause anyone willing to use MIT software any troubles other than forcing them to be good OSS citizens.

My argument, such as it is, is that I'm unfamiliar with it and it's long and complicated and it's not the license the project had when I started contributing. I'm just trying to figure out if it's necessary for me to go through the hassle of analyzing a license that I'm unfamiliar with that's 700% longer than the MIT license. I'm trying to understand what's compelling about this license vs others like MIT before I go to the trouble. Re: # 2 that's my whole point -- I'm unfamiliar with it, so I don't know that yet and it's way longer than MIT. Do you happen to have links to any comparisons of the 2 licenses by credible sources (I'm talking about something with more substance and credibility than the tldrlegal.com link).

Thanks

[joeybaker]

@jmm

Jesse–

First off, thank you again for both using and contributing to remapify! I understand the desire to know what you're getting into. Let me see if I can address your points one by one:

1. The value of enforcing a changelog if you intend to distribute a modified version is that it allows users to clearly see the difference between a fork and the original; allowing them to make an informed decision over which to use. This is not only common courtesy, but common practice. I'm confused why you don't see the value, but it is something that I strongly support and I like that this license does too.
2. The summary is based on the reading of the license. It is also not a lawyer.
3. Yes, I believe that the Artistic license reduces confusion if there is a fork. Again, this is because of the changelog provision and the (some what muddled) re-naming provision.
4. I'm not a lawyer, and you haven't said you are either, so I understand that it's a lot of legalese. However the Artistic 2.0 license is only 1367 words. That puts it at less then the 1577 words of Apache 2.0 license. (I took the time to look that up :] )! It's really not that long.
5. The Artistic license is written by the Perl Foundation. It's both well maintained and in common use.
6. I do not have any links beyond what I've already linked to explain the license. Google might.

Again, I empathize with your concerns over wanting to understand the legal framework for a project you're contributing to and using. I'm also very thankful for your contributions.

In the process of replying to you I've read the license at least 3 times in full and have spent far more time typing responses then reading it – I suspect the same applies to you! If you want to understand the license I suggest you read it as well.

I have no intention of reverting back the MIT license, which I hadn't ever intended to release this under. The change to the Artistic License was fixing an oversight on my part.

Please do whatever research you'd like to decide if you're comfortable with using and contributing to the project. I'll be a sad if you decide not to, but will understand.

[jmm]

1. I'm just not convinced it's necessary / effective enough as a license clause to justify using a less mainstream license that is far more complex.
2. Based on my interpretation of the license, that summary is wrong.
3. The renaming provision doesn't seem muddled to me. In practical terms I don't think there is a requirement to rename. The changelog provision seems pretty hokey to me -- very subjective for one thing.
4. In my opinion it's long relative to its mainstream-ness and proposed benefits.
5. In common use where, Perl's core? Since you pointed it out, I now know it's used for npm, which is one widely used application.

Maybe someday it'll make sense for me to pore over the license, but I'm not eager to do it right now.

In the meanwhile, here's where I'm at:

aliasify's (undocumented) ability to do this kind of thing might meet my needs for now:

aliasify = require('aliasify').configure({
  aliases: {
    "app": "./src",
    "view": "./src/view",
  }
});

browserify('./src/entry.js')
  .transform(aliasify)

// src/entry.js
require('app/model/whatever');
require('view/whatever');

I've also started exploring an alternative solution that is more elegant and powerful than either aliasify or remapify, but a bit brittle with the current browserify API.

[joeybaker]

@jmm I'm glad you found a solution and I appreciate your work on both remapify and browserify itself. I'm going to close this issue because I do not intend to change the license to MIT. Please reopen if you feel differently