Upgrade the license to an open one

[abh]

I realize you probably picked deliberately, but I will ask anyway. :-)

For personal use the license is fine, but it would be nicer if the software had a properly open license (apache, bsd or MIT for example) for "corporate use". It's not about not contributing back, but just the added legal hassle using contagious licenses in anything.

[ShaneCurcuru]

I would certainly look at the Aapche Individual CLA: https://www.apache.org/licenses/icla.txt

The difference between signing a CLA with the ASF and signing something with Steve is that the ASF's CLA notes "the Foundation shall not use Your Contributions in a way that is contrary to the public benefit or inconsistent with its nonprofit status and bylaws in effect at the time of the Contribution". Since the CLA allows sublicensing, the recipient is covered, but the donor has to trust the recipient. With the ASF, hopefully we have a long history of keeping our Apache license.

I agree copyright assignments are not good, but if you can get the community to think about this specific problem, all you need is for various authors to assign "enough" rights to the contributions already in this codebase to allow the primary author to relicense. Personally, if I had been contributing, I'd be happy to give Steve my copyrights to specific changes here if it made things easier. But again, personally, I'm waiting until it's under the Apache license before I contribute. 8-)

One actionable suggestion: it would be nice both to contributors and to users if this plan and the status of the licensing were more obvious on the front page of the project.

[bep]

This should be fixed. I may have signed this CLA, but wasn't even considering it would "sign away my copyrights", but I'm happy with the relicense/change.

[abh]

As the person opening the issue I'll just state that switching to GPL 2 (or even worse GPL 3) would not fix "the main issue".

[spf13]

After a careful reading of the Apache CLA, it assigns rights to the Apache Foundation and does not permit for changing the license in the manner which we desire to for Hugo.

So as soon as we have sign off of all contributors with "active" contributions we will change the license to Apache 2.0 and change to using the DCO http://developercertificate.org as the CLA for the project.

I wrote a program to analyze all PRs and who has signed. Here is the output: https://gist.github.com/spf13/fe97ded396faefff1ba9

I will reach out to everyone on this list and request they click the button to sign the current CLA. We will explore rewriting remaining code in a week. I currently don't examine this along with git blame so some unsigned contributions may not be relevant.

I'll update the Gist throughout the week.

The email to these contributions will read as follows.

X, In order to facilitate an even more open community and additional contributions the Hugo team has decided to change the Hugo project (github.com/spf13/hugo) to the Apache 2.0 license from the current license (SimPL-2.0). To change licenses requires approval from all contributors. The simplest way to do is to have everyone assign rights to their Hugo contributions to the project owner so we can change the license. Once we have released Hugo under the Apache 2.0 license we will change to project to utilize the DCO http://developercertificate.org as the CLA for the project.

To sign simply go to https://cla-assistant.io/spf13/hugo and click the button to agree to the CLA.

Please do it now, it only takes 5 seconds and will enable us to make this critical change. 

Best, Steve

[spf13]

@bojako @zackp30 @danke-click @hagbarddenstore @rawfalafel @stevenshchin @rauhs @tummychow @jamesmcmahon

I wasn't able to find email addresses or any other contact information for you. Trying to notify you here. Please sign the CLA linked in the comment above.

[JamesMcMahon]

Signed. Link above was broken, correct link is https://cla-assistant.io/spf13/hugo.

[spf13]

oh weird. It linked that oddly. Thanks @JamesMcMahon.

[bep]

After a careful reading of the Apache CLA, it assigns rights to the Apache Foundation and does not permit for changing the license in the manner which we desire to for Hugo.

Lawyers in here may chime in, but why does the future CLA need to permit a license change?

What is needed, in my head, is:

1. The CLA for future contributions should be Apache (with no Copyright Assignment)
2. For the license change approvals from the contributors of the past: "Is it OK if we change the license of your contributions ...? Yes or No?"

[spf13]

I apologize, I didn't word that very clearly. Let me clarify and expand here.

Why DCO over Apache CLA?

After significant research I decided to go with the DCO for a few reasons:

1. It works in a general fashion (apache doesn't)
2. It assigns only the minimum rights needed to apply an open source license.
3. It requires the contributor to warrant that the code is clean in all the ways that protect the project.
4. It does this in the most succinct way possible without any extra fluff.

The DCO works well because it leverages the license that is applied for the terms rather than redefining them in the CLA itself. In this sense the DCO is the minimal way to ensure that the contribution adheres to the Apache 2.0 license.

In contrast the Apache CLA was designed for projects that the Apache foundation has ownership of. It assigns more rights directly to them and requires contributors to warrant and grant significantly more things. It is considerably and needlessly longer, duplicating much of the Apache 2.0 license in it's text. It's not intended for general use, but specifically for the Apache Foundation.

As for the current CLA/Waivers.

The Simpl 2.0 license doesn't permit for sub licensing. This means we can't just change the license... which is a good thing. It's one of the protections built into the license. The safest way to change the license from a legal perspective is for all rights to all contributions to be granted to a single copywriter holder who then can legally change the license. The current text also explicitly calls out that they grant him permission to change the license to Apache 2.0. This provides protection so nobody later can say that they don't agree with the license change and sue me personally as the one who made the change. They have in effect given up their rights to doing so when they signed the CLA. Now I don't think anyone would do that, but that's not the point. The point is that we need to do this the right way and do it once so that everyone in the future can feel comfortable that it's 100% clean.

Does this all make sense. I'm sorry we have to go through this. Looking back 3 years to when I released Hugo, virtually all of my personal experience with my own open source projects was scripting languages where the source and the running application were synonymous. As I looked to what the community used on complied projects for direction I found a significant amount used the GPL. It does provide more protection for contributors than the more open licenses like MIT, BSD and Apache. I pretty well hate legalese and liked the plain text rendering that the simpl 2.0 license provided. Thanks to very helpful people I have seen the light and now realize that using a standard and pre-approved license will enable corporate employees to safely contribute without unnecessary friction with lawyers. After consulting with lawyers with expertise in open source licensing law (yes, those do exist), I determined that the Apache license was the best fit providing the best protection for the project and all those who contribute while remaining open enough to facilitate easy contributions.

I thank everyone for their understanding and support as we make this change. I know that the project will be even more successful in the future as a result.

[bep]

The Simpl 2.0 license doesn't permit for sub licensing. This means we can't just change the license... which is a good thing. It's one of the protections built into the license.

No, but as this is a contractual thing, it is perfectly fine to just agree on the change of license.

The safest way to change the license from a legal perspective is for all rights to all contributions to be granted to a single copywriter holder who then can legally change the license.

I don't believe this to be correct, but it's your project, do as you please. I just wanted to say that I don't agree.

[willnorris]

Allow our employees to sign a document assigning away "all rights to contributions of ideas, code, documentation, or work provided to this project"?

Providing a license to the contribution is one thing, but as I said earlier, a copyright _assignment_ is a non-starter.

[robertmeta]

@willnorris Would copyright license make everything acceptable -- or is that still an issue?

[willnorris]

@willnorris Can you explain why this is an issue? I understand it sounds scary, but isn't it specifically on contributions to the project, and exists in a ton of CLAs for (it is my understand) worldwide distribution reasons.

I am legitimately trying to understand the practical implications of this.

This is not at all common in CLAs. In fact, it couldn't accurately even be called a Contributor License Agreement at this point, it's a Copyright Assignment. The most notable group that does copyright assignment is the FSF, and they do it largely so that they can actively go after violators of the GPL. (Only the copyright holder can sue for copyright violation, which is why the plaintiff in the current VMWare Linux Lawsuit is an individual kernel contributor, since he is the copyright holder in that case.)

A standard CLA gives the project a non-exclusive license to use the contribution under the terms of the agreement. So the contributor is still the owner of the code, and they are still free to use it however they want, even in ways that are otherwise incongruous with the license of the the project they contributed it to. For example, I could submit a patch to a GPL licensed project, and then later submit the same patch to an MIT licensed project. Or do anything else I want to with it... it's my code.

If however, I assign that copyright to someone else, then I no longer have any rights to use my own code except as defined by the license of the project. In some cases, that might not be a big deal, but it's not something we would do without a really good reason. (For what it's worth, Google has signed FSF's copyright assignment.)

---

https://cla-assistant.io/spf13/hugo has the additional problem that it is not only a copyright assignment, but could be read to include both a patent and trademark assignment (the "all rights to contributions of ideas, code, documentation, or work provided to this project" language that I mentioned above).

The FSF copyright assignment language is very specific about calling out that patents are licensed, not assigned:

I hereby agree that if I have or acquire hereafter any patent or interface copyright or other intellectual property interest dominating the program enhanced by the Work (or use of that program), such dominating interest will not be used to undermine the effect of this assignment, i.e. the Foundation and the general public will be licensed to use, in that program and its derivative works, without royalty or limitation, the subject matter of the dominating interest. This license provision will be binding on my heirs, assignees, or other successors to the dominating interest, as well as on me.

See also the Legal Matters chapter from Producing OSS that goes into further detail.

[willnorris]

@willnorris Would copyright license make everything acceptable -- or is that still an issue?

yes, depending on the actual language of the agreement, a copyright license would be fine, and is the appropriate tool... that's exactly what we do for our own projects.

I'm fairly certain that our lawyers believe the Apache CLA to include the ability to relicense, but I'd have to double check that. If that's a concern though, then add language that explicitly grants the right to relicense as Apache 2.0, similar to what https://cla-assistant.io/spf13/hugo currently has. Or execute a separate agreement that just grants the right to relicense for all SimPL contributors, and then use the DCO going forward, which I think was Steve's preference.

[hagbarddenstore]

There, I've signed it. I can be reached at hagbarddenstore@gmail.com.

[vorot93]

I grant Steve Francia all rights to contributions of ideas, code, documentation

Sorry, but nope. I'd agree if you simply wanted to change the license. But my contributions remain mine.

[bep]

Just to make this crystal clear if I haven't already: I don't agree with the mentioned CLA, so any relicensing using this CLA will have to be without my contributions.

I'm happy to relicense, but with an adjusted CLA as discussed above.

[spf13]

I'm working on a revised CLA based on feedback here and have asked @willnorris for help ensuring it's acceptable. Thanks for your patience on this.

[bep]

I might as well put this one into the open as well: I have read @spf13 s new revised suggested CLA, and it addresses my concerns to the point. Happy to sign it. Then we can get this damn Hugo 1.5 out the door.

[spf13]

@bep I've updated the CLA to a friendlier one.

[JamesMcMahon]

That's a good change Steve. What does this mean for people that have perviously signed the CLA?

[spf13]

If you've already signed, you're covered legally with the switch we're about to do. People are welcome to sign this one if they want. It's very short lived though, and will be replaced by the standard DCO as soon as Hugo 0.15 (under Apache) is released.

[willnorris]

New CLA text looks good. Thanks @spf13!

[spf13]

Thanks for the help @willnorris

[bramp]

Thanks @willnorris, @spf13, and others. I have now signed.

[bep]

Signed, sealed -- now deliver Hugo 0.15!

[spf13]

All current contributors have signed the CLA. I have changed the license over to Apache 2.0 and switched the CLA over to the DCO. It is finished.

[github-actions[bot]]

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