Add an official license to VVV

[jeremyfelt]

Is anyone well versed on this?

1. Do we need a license?
   • I think yes to explicitly indicate “we’re open source” versus the default terms and assumptions provided by GitHub.
2. If yes, what should the license be?
   • GPLv2 or later seems like a good answer at first glance, but maybe something along the lines of MIT is a better fit. I don't want to restrict anything.
3. Does anything provided in the default VVV package conflict?
   • There was a time when we included a few things as a whole in the package, but now they are all pulled in via script.

[aaronjorbin]

1. Yes. Ambiguity is best when it is avoided.

2. Both GPLv2 and MIT are good choices in my book. http://choosealicense.com/ says that MIT is best for when you want "Simple and Permissive" while GPL is best for when you "care about sharing improvements".

3. https://github.com/Varying-Vagrant-Vagrants/VVV/blob/master/config/wordpress-config/wp-tests-config.php has it's roots in WordPress. Not sure if that is enough to require us to be GPL. Of course, IANAL.

[jeremyfelt]

The WordPress config is an interesting point and worth thinking through. I've often wondered the same thing about other config files for nginx, MySQL, etc...

I've thought about using GPL quite a bit, but I'm hesitant to think about sharing restrictions on a conglomeration of scripts and config files. Overall, I'd probably still lean that way.

Worth noting in this project space:

• Salt, Puppet, Chef, and Docker are Apache 2.0
• Ansible is GPLv3
• VirtualBox is GPLv2
• Vagrant is MIT

[simonwheatley]

1. IMO Yes we do, otherwise it's source which happens to be openly visible, not Free Open Source Software.
2. I tend to go GPL v2 for everything myself, but IANAL (or anything but an amateur software licensing spectator)
3. As far as I can see (insert usual caveats here) we don't have anything which forces us to be GPL. I would argue that the WordPress config bits @aaronjorbin refers to are not something VVV is integrating with, therefore not something which "infects" VVV … but I'm going to back down on this argument quite quickly in a heavy software licensing discussion.

Overall, from me, +1 for GPL and I'm happy to retrospectively contribute any code under that licence.

[jeremyfelt]

Ok, I'm leaning GPLv2 or later to go with the familiar.

Does anybody know how this affects existing forks of VVV? I'd imagine that those inherit the license that existed at the time of the fork. I don't have a problem with that, but don't want to make it difficult on anyone else either.

[jeremyfelt]

Ping @westonruter for thoughts as well. :)

[westonruter]

For my open source projects, I'm a fan of dual licensing, following the model of jQuery, which is dual-licensed GPL/MIT (or at least it used to be). Forkers can choose whichever license fits their use case.

[jeremyfelt]

Interesting. I did not know of this magical world and I kind of like it.

@aaronjorbin, @simonwheatley - Dual licensed as GPLv2 or later and MIT?

[ericmann]

My vote would be MIT or at least dual license. GPL forces itself on derivatives, and I'm all for giving forkers the freedom to use whatever OS license they choose. That's why I use MIT where I can and only GPL where required by existing licenses.

[itsananderson]

+1 @ericmann. Some large companies* would think twice about contributing to a GPL project or integrating it into their services, but are much more friendly toward MIT.

• * Source: I work for Microsoft**
• ** This comment represents my opinion, not Microsoft's ;)

[simonwheatley]

I'm happy to go with dual licensing.

[pento]

I'm strongly in favour of GPL only.

I'm against MIT, for the same reason that @ericmann is for it - it doesn't force forks or derivative projects to be an open source license. I'm yet to come across a GPL project that has suffered from this requirement. To use the Microsoft example, if a company wants to integrate an open source project into their profit-making machine, the least they can do is contribute any improvements they make back to the community - the GPL just enforces that. Without the GPL, I'd suggest that they're more likely to never bother contributing back.

As a side note unrelated to the specific license you choose, any license change you make will probably need permission from all contributors to the project to date.

[ericmann]

Let's stop using hypothetical examples here, particularly with Microsoft as the scapegoat. For the record, that particular for-profit company has already contributed a significant amount back to the Vagrant project itself. Also, Vagrant itself is licensed as MIT, so there's no reason they or anyone else is required to contribute back their changes.

I love open source, but I also recognize there are situations where viral OS licenses (like the GPL) are inappropriate: namely many government, healthcare, and financial environments. Applying a GPL license to our project will effectively cut out potential contributions from those projects. I'd rather risk a greedy for-profit using our software within a closed environment than cut off a large part of the community like that.

[jeremyfelt]

Great comments, thanks everyone. There's a lesson to be learned in all of this to not wait 1.5 years to pick a license. :)

As a side note unrelated to the specific license you choose, any license change you make will probably need permission from all contributors to the project to date.

This is an excellent point, @pento. I hadn't thought about it from that angle yet. We do need to get everyone on board for a final decision.

I'm going to continue doing some reading. I think at some point we'll need to lay down our options and start poking contributors directly.

Continued discussion is welcome!

[jeremyfelt]

Other notes / reads of interest:

• It took Bootstrap almost 2 years to re-license as MIT. They had 368 contributors to poll at the time. There are some great points in that thread.
• https://github.com/beberlei/license-manager may come in handy for soliciting contributor approval.
• Notes from Open Street Map's re-licensing - "What happens if not everyone agrees?"
• jQuery removed the GPL from their dual GPL/MIT license in 2012.

there are situations where viral OS licenses (like the GPL) are inappropriate: namely many government, healthcare, and financial environments.

@ericmann - would you mind expanding on this a bit? I'm not sure about the term viral, even though I'm learning that it's been used to describe the GPL over the years. From my understanding—somewhat from GNU's US government note—use of VVV and contributions back to VVV would likely be fine for those groups if licensed under GPL. The restrictions would come from public redistribution of modified source or software that incorporates VVV.

[ericmann]

The GPL is called "viral" because any derivative projects must also be licensed under the GPL (i.e. the license "infects" derivative works).

The issue with GPL software is one of distribution, but not necessarily to the public. If I use GPL software (i.e. WordPress) to host your website, you as the consumer never receive the software itself - therefore I don't necessarily have to give you a copy of the source code. This is how companies like Automattic and WPEngine can use WordPress (GPL) in specially modified forms (also GPL) for hosting without being required to give their modified copies to their customers.

Likewise, a GPL-licensed version of VVV used to spin up a remote environment would not trigger the distribution/source-availability clause of the license for anyone who uses the environment through, say, a web browser.

However, the tricky part comes in when dealing with development teams. If my hosting tools are GPL, and I hire you as a contractor to work on the project, I have to give you access to the code itself. Under the GPL, you're now entitled to your own copy and have the right to distribute that copy on your own.

So, if VVV (licensed as GPL) is being used by a dev team in-house, and they need to add proprietary magic to it to simulate their internal hosting environment, the derived VM generation package would also need to be licensed under the GPL. Developers, either in-house or subcontracted, would then have the right to repurpose and redistribute this otherwise proprietary code. I can tell you from personal experience this will not fly in many healthcare, gov't, and financial organizations since, even though they use open source (read: MIT, BSD, Apache licenses), they still have code that is necessarily private and proprietary.

Also of note: MIT is "GPL compatible" so we could license VVV as MIT, then forkers could distribute their own forks as GPLv2/3. We can't do it the other way around, though.

[zamoose]

@ericmann:
Given that, what is the purpose of even discussing dual-licensing? Is it a
terrible thing to just go with MIT and be done?

On Thu, May 22, 2014 at 1:33 PM, Eric Mann notifications@github.com wrote:

The GPL is called "viral" because any derivative projects must also be
licensed under the GPL (i.e. the license "infects" derivative works).

The issue with GPL software is one of distribution, but not necessarily to
the public. If I use GPL software (i.e. WordPress) to host your website,
you as the consumer never receive the software itself - therefore I don't
necessarily have to give you a copy of the source code. This is how
companies like Automattic and WPEngine can use WordPress (GPL) in specially
modified forms (also GPL) for hosting without being required to give their
modified copies to their customers.

Likewise, a GPL-licensed version of VVV used to spin up a remote
environment would not trigger the distribution/source-availability clause
of the license for anyone who uses the environment through, say, a web
browser.

However, the tricky part comes in when dealing with development teams.
If my hosting tools are GPL, and I hire you as a contractor to work on the
project, I have to give you access to the code itself. Under the GPL,
you're now entitled to your own copy and have the right to distribute
that copy on your own.

So, if VVV (licensed as GPL) is being used by a dev team in-house, and
they need to add proprietary magic to it to simulate their internal hosting
environment, the derived VM generation package would also need to be
licensed under the GPL. Developers, either in-house or subcontracted, would
then have the right to repurpose and redistribute this otherwise
proprietary code. I can tell you from personal experience this will not fly
in many healthcare, gov't, and financial organizations since, even though
they use open source (read: MIT, BSD, Apache licenses), they still have
code that is necessarily private and proprietary.

Reply to this email directly or view it on GitHubhttps://github.com//issues/346#issuecomment-43919219
.

-Doug

[jeremyfelt]

Interesting point on the distribution to contractors. FYI for anyone, that's covered in this FAQ item.

Things like "Proprietary magic" and "secret sauce" (that second not via @ericmann's) do get to me though. I guess this is the part where I could lean toward GPL as I'm not convinced those have a place in open source software.

I think our plugins system is also worth considering as part of this. Additional scripts can be run on top of the base VVV environment to add the magic sauce without being covered by VVV's license.

[jeremyfelt]

Hmm, my thoughts on plugins may be off. https://drupal.org/licensing/faq/#q7

[adamsilverstein]

I think the MIT license seems most appropriate, given @ericmann's persuasive arguments above - seems like this would allow the widest options for contribution back to the project. If you can't get all existing contributors on board, a joint MIT/GPL license might be a good compromise.

[JJJ]

Let's say someone starts a business around hosting VVV powered remote environments. According to @ericmann's assessment:

• If VVV were GPL licensed, it is within anyone who leaves this business's right to open-source all of the extra non-VVV bits, as they are likely to also be GPL.
• If VVV were MIT licensed, the secret sauce could be explicitly licensed as some-other-thing, allowing the business's secrets to remain as secret as they desire.

Personally, I agree with @adamsilverstein's assessment above.

[TheLastCicada]

Since we're going to fund this work 2 cents at a time, here's mine....

The question of licensing is more one of mission for this project. The 2 options are....

1. Is it meant to be a fully open source platform always open to everyone to use non-commercially for local development? If you don't like that mission, create your own Vagrant and leave VVV out of it. This sounds like GPL from what I'm hearing.

or...

1. Is this meant to be a useful tool, supported by an open source community, that can be used for or altered to do whatever you want, commercial or non-commercial, to meet the needs of the absolute most people and use cases, regardless of what weird restrictions they may need to put on it. This sounds to me like MIT.

If I think back to when this project started (and @jeremyfelt can tell me if I have revisionist history here), we didn't set out to create god's gift to development environments, it was supposed to show what you could do with Vagrant in making a local development environment match what in on a production server and make that approachable. The point was that this would work well enough, but if you had specific needs or you wanted a Vagrant environment to match your host setup (say WPEngine or Dreamhost or you run it with Apache) that you'd use VVV as a reference, but you'd go setup your own Vagrantfile and box and share it on Github yourself, or not share it at all. If that is still the mission here, then GPL seems appropriate as it makes no attempts to cater to these individual use cases. There's nothing stopping anyone from building their own Vagrant development environment that looks a lot like VVV and keeping that in-house and slapping a restrictive license on it - there's no patent on "apt-get install nginx" (I'm screwed if there is). All the tools that built this are free, it isn't magic. If you are going to use VVV, then it is free and you can deal with it. This could have the side-effect of other Vagrant development environments making it out into the world, which would be a good thing from my point of view.

That being said, I see lots of merits in the MIT license as well and could be persuaded. It comes down to what the goal of this project is and what the mission is.

[jeremyfelt]

If VVV were GPL licensed, it is within anyone who leaves this business's right to open-source all of the extra non-VVV bits, as they are likely to also be GPL.

Only for contractors. Internal distribution is a different matter. http://www.gnu.org/licenses/gpl-faq.html#InternalDistribution Though with today's type of workforces—heck, with software development in general—contractors can be the norm.

we didn't set out to create god's gift to development environments

Only to break up with MAMP, which is not MIT or GPL! :)

Is this meant to be a useful tool, supported by an open source community, that can be used for or altered to do whatever you want, commercial or non-commercial, to meet the needs of the absolute most people and use cases, regardless of what weird restrictions they may need to put on it. This sounds to me like MIT.

I really like the GPL. But I also really like this point from @TheLastCicada.

[jeremyfelt]

So I think I've been able to solidify my opinion on this.

From the current README:

VVV as a Scaffold

Entirely different server configurations can be created by modifying
the files included with VVV and through the use of additional Auto 
Site Setup provisioning scripts.

It is not necessary to track the changes made to the main repository.
Feel free to check this project out and then change everything to
make it your own.

The README has changed a lot from the original, though both do focus on digging around and making it your own.

The intent of that digging around and making it your own is educational. The purpose of creating the repository originally was to learn how Vagrant worked and narrate the process. Once it blew my mind, the purpose quickly became educating as many as possible because this really is hot stuff.

I think if we were starting from scratch, I would want to use the GPL out of principle. I really do think it is an appropriate license. And I have no problem with its viralness (virality?) virulence. Mostly because I don't see it as viral, but fair—with usage driven by choice rather than contraction.

All that said.

I think MIT is the most appropriate license at this time. This better fits the current description of VVV as a scaffold in the README that wants you to take it and change it and learn how it works. I feel like it better fits what has been implied about the project over the last 1.5 years.

I would also be okay with a dual license, so that a derivative work could redistribute their entire package under the GPL. I'm not sure if that's more pain than its worth. It may be worth studying the jQuery example to see what drove that decision.

[dwlf]

@jeremyfelt how are you looking on getting this issue resolved? Please don't dual or tri-license (Mozilla!) this. GPL v2+ likely matches the community's expectations.

[jeremyfelt]

@lloydde I'd like to try and wrap this up soon. We'll do a proper vote with all those who have contributed. Per the discussion here, I'm going to recommend MIT. I agree with GPL in principle, but that was a choice that I think needed to be made earlier.

[jeremyfelt]

And agreed - no dual license. :)

[jeremyfelt]

Reminder ping to @carldanley, @mbijon, @alexw23, @vDevices, @aaronjorbin. Yes/No vote on MIT, please. :)

[aaronjorbin]

Let me ask my 🎱

It says:
Apache 2 or GTFO

I kid. MIT works for me.

[carldanley]

MIT ftw! 💯

[jeremyfelt]

Thanks!

We're down to @mbijon, @alexw23, and @vDevices. Close!

#453 is ready for merging when we get there. :)

[mbijon]

@jeremyfelt I absolutely agree with the MIT licensing of my contrib & the whole project: yay

[BadgersFanFan]

I vote for MIT.

[cfoellmann]

One to go: @alexw23

[alexw23]

Nil stance from me.

On 8 Oct 2014, at 2:43 am, Christian Foellmann notifications@github.com wrote:

One to go: @alexw23

—
Reply to this email directly or view it on GitHub.

[jeremyfelt]

Whoa. I think we're good then. Thanks all!

[dwlf]

@jeremyfelt right on!

Now that the issue is behind you, I just wanted to correct something @nacin wrote, though IANAL & TINLA, "Around the time they discussed dropping the GPL, I was talking with the jQuery team and I realized they had actually only ever licensed it as GPLv2, not GPLv2 or later like Drupal and WordPress. Thus it was incompatible with Drupal's license from the beginning, and so they were using it essentially as an MIT library that whole time. Funny, that."

It is incorrect that "it was incompatible with Drupal's license". A GPLv2 license is compatible with a GPLv2+ license. What would not be compatible would be a GPLv2 and GPLv3 code, for example.

[nacin]

I have little desire to get into a licensing discussion, but I stand by what I wrote. Drupal and WordPress are both licensed as GPLv2 or later. We cannot incorporate code that is GPLv2 (only) into WordPress itself, as we cannot distribute the complete work as GPLv2 or later. Are they compatible? Yes, they are. Does that matter for our situation? No, it does not.

Right now, you could take Drupal and redistribute it as GPLv3. If Drupal included GPLv2-only code, you could not do that. My point was that for all intents and purposes, jQuery was always used within the Drupal project as MIT code.

[dwlf]

You are confused. What you are writing now is not the same thing as "it was incompatible with Drupal's license". Intent or goals is not the same thing as compatibility. I have dual/tri license experience back from my Mozilla days, which is what this topic really is. The only way to conclude that "jQuery was always used within the Drupal project as MIT code" is if there was other shipped code in Drupal that was incompatible with GPLv2.

[markjaquith]

Drupal was released under GPLv2 and GPLv3.

jQuery was released under GPLv2 and MIT.

Which jQuery license choice is compatible with both of Drupal’s licensing choices? Just MIT. This is the point. No more.

[dwlf]

Thanks Mark. That's a better way of putting it. It's about forward compatibility. The suggestion that GPLv2 was incompatible with GPLv2+ was absurd.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.