Consider using a more permissive license

[devinus]

No description provided.

[blt]

Any particular reason? (Also, consider issue #4.)

[devinus]

I'd like to use the Proper runtime in several projects, and it raises too many questions. For instance, linking Proper into rebar to automatically run Proper tests is already of questionable legality. Many companies are also deathly allergic to GPL code being used. Many smaller shops also don't have the money to hire a lawyer to navigate the waters themselves. Proper being GPL is literally the only thing keeping me from using it. The GPL is confusing, and you get the spirit of copyleft with the Apache license instead.

[blt]

I tend to agree with you and thought your issue ticket would be stronger with elaboration.

I find the answer given in issue #4 unconvincing: PropEr is much less like GCC and more like GNU Readline, the use of which does spread the GPL license to client code-bases.

+1

[devinus]

@blt Exactly. I don't use Proper like a command line tool. I hate to admit that Proper being GPL licensed is a such a turn-off but it really is, and a lot of people feel that way.

[blt]

The GPL is a very opinionated license, one whose primary purpose is a tool for social change. In that regard its been remarkably effective. The project authors might well intend PropEr to be a tool for social change, making its stated function as a property based testing tool for Erlang secondary, especially for those projects not licensed under the GPL.

My open-source code is generally available under the MIT license. At a minimum, any project in which I make use of PropEr will have GPL test code, rather a frustration.

[toland]

+1

I think many developers want to respect a library author's wishes with respect to copying but are confused by the GPL. It can be difficult to fully understand your obligations as a user of GPL code and so you are left with two options: 1) use the code and comply as best you can then hope nobody calls you out, or 2) more likely, avoid the GPL code altogether.

[kostis]

GPL v3 was chosen primarily due to its strong copyleft properties.
An added bonus is that it encourages open source software which we are strong proponents of.

In all talks we have given, we have made it absolutely clear that the GPL restrictions are lifted for all open source projects that want to use PropEr, irrespective of their licenses -- i.e. their code bases are not contaminated by GPL in any way. However, I understand that this should also be made clear in writing somehow and in this respect the current situation with the PropEr license is problematic. But I want to stress that as far as we are concerned, there is no issue (and will never be any) in using PropEr in open source projects, even commercial ones.

Following discussions with many developers at the Erlang Factory in SF we are considering offering the possibility for closed source projects to obtain explicit licenses to use PropEr, for a fee. However, the details of how to best do that are not at all clear at this time - we do not have and do not want to form a company around PropEr at this point.

It would help us enormously if:

1. You can point us to another license that is strong copyleft and allows unrestricted use of the tool in open source projects only.
2. You can elaborate what currently stops you from using PropEr in open source projects (esp. after we add an explicit statement that the GPL v3 restrictions are lifted for open source code bases that use PropEr) and whether the possibility to offer non-GPL licenses for a fee will resolve the issue for all (presumably commercial) closed source projects.

[blt]

1. You can point us to another license that is strong copyleft and allows unrestricted use of the tool in open source projects only.

If your goal is to ensure that all derivative works are distributed under the same license as PropEr, there's nothing better than the GPL. Arguably, that's the GPL's stand-out feature.

1. You can elaborate what currently stops you from using PropEr in open source projects (esp. after we add an explicit statement that the GPL v3 restrictions are lifted for open source code bases that use PropEr) and whether the possibility to offer non-GPL licenses for a fee will resolve the issue for all (presumably commercial) closed source projects.

I release my code under permissive licenses, rather than copyleft. My concern with PropEr's licensing is that it's not at all clear how derivative works of my works will be effected. Say I release an MIT licensed work and PropEr's license is amended to grant exceptions to the GPL's share-alike requirements for the MIT license. What happens to a proprietary code-base that makes use of my MIT licensed work?

Possibilities:

• Proprietary derivative works of my software are constrained according to the terms of the MIT license only, effectively nullifying PropEr's GPL license.
• Proprietary derivative works of my software are constrained according to the terms of the MIT license and PropEr's GPL license, effectively negating my ability to license an open work under anything not copyleft.

If the later is the case, I will be unable to use PropEr in my Open Source projects. If the former is your intention, you might as well re-license PropEr. (Consider that it would be possible to re-license PropEr by 'force': a permissively licensed shim over GPL PropEr would, in effect, remove the share-alike requirements.)

In addition, as @toland mentioned, it can be difficult to determine one's obligations under the GPL, mostly due to complications between jurisdictions of what constitutes a derivative work. Consider this:

• PropEr is used in a proprietary codebase, linked only during development.
• The proprietary product is distributed without PropEr linked.
• The test source code is never distributed.

It's not entirely clear to me if, in the United States, the proprietary codebase would be a derivative work of PropEr (the test code certainly would be). If I understand you, it is your intention that the whole work would be considered a derivative?

[blt]

If you intend for this project to be usable by open source projects, you might state that and make an explicit exception in your license. For instance, basho recently pulled PropEr support from erlang_protobuffs.

[devinus]

Is there any chance of this happening?

[kostis]

If by this you refer to adopting a license that is not strong copyleft or allows unrestricted use of PropEr in closed source applications, then the answer is no for the time being.

If your comment refers to adding an explicit (and hopefully clear) exception from the "infectious nature" of the GNU license for all open source code bases, the answer is that this should have happened long ago (I apologize for this delay) and it WILL happen (hopefully) soon. Our intention is to encourage the use of PropEr in projects like e.g. poolboy and I welcome you to share your thoughts, here or privately or even better in the properATsoftlabDOTntuaDOTgr mail alias which reaches all PropEr developers, on how to best add this exception.

But we do not consider adopting a non copyleft license at this point or allow use unrestricted of PropEr in closed-source projects.

[devinus]

@kostis Indeed, I was referring to an exception clause to make it clear that library authors using it for tests aren't "infected" by the GPL.

[devinus]

@kostis Another license that puts your needs in clear terms (non-commercial use restricted) and isn't contagious is the simple Creative Commons Attribution-NonCommercial-ShareAlike license:

http://creativecommons.org/licenses/by-nc-sa/3.0/

[essen]

Pardon me, you must be really tired of hearing about it, but I must insist on this issue.

[zkessin]

How about the LGPL Or the MPL? both I think may make everyone happy

What my issue is is that I would love to use Prope in say Erlog, but leave erlog under the MIT Licence so that it can be used by closed source projects

[andrzejsliwa]

Good example of license exception you will find in GCC: http://www.gnu.org/licenses/gcc-exception.html.
Please remember that we all using every day GCC thanks to that exception. Without this license exception even using Erlang compiled with GCC would be impossible.

now we have really strong polarisation on QuickCheck in Erlang community:

• commercial EQC but mostly to expensive for most of us. (EQC mini without support for state, fsm, etc not solving the cost problem)
• gpl3 PropEr which is free but we can't use it to build our daily (still)close sourced apps.

the result is that QuickCheck instead to be more popular is used only by small part of Erlang community.

[essen]

Don't forget krestenkrab/triq which is Apache License 2. I am going with it and am writing an erlang.mk plugin for it as we speak.

[RomanShestakov]

I am also going to use triq, would love to use Proper but our company policy doesn't allow use of GPL. LGPL is allowed though, Is it possible to switch from GPL3->LGPL?

[zuiderkwast]

I have digged into the Erlang+GPL topic because I too am a fan of GPL 3 and copyleft.

The problem with Erlang applications is that they are not actually separate programs in terms of GPL but they must be seen as libraries. An OTP application can call functions in another OTP application. That actually makes the OTP applications "derived work" of each other in terms of GPL.

In #4 @manopapad mentions GCC being GPL. The license of GCC actually "GNU GPL 3+ with GCC Runtime Library Exception" (license text), which is a linking exception. Without that linking exception, everything you compile with it would become GPL. GPL 3 is very clear about this in section 5 Conveying Modified Source Versions. Many software project are licensed under similar variants of "GPL + linking exception" (Wikipedia link), e.g. GNU Classpath. LGPL is another linking exception to GPL that is often used for libraries that need to be used together with non-GPL software.

@kostis

In all talks we have given, we have made it absolutely clear that the GPL restrictions are lifted for all open source projects that want to use PropEr, irrespective of their licenses

LGPL 3 (or one of the orther "GPL + linking exception" licenses) is exactly this phrased in a legal way. LGPL says that any modifications to PropEr itself are subject to GPL (thus strong copyleft is preserved for the library itself) but other programs using PropEr as a library are not "infected" by the GPL. (LGPL 3 license text here).

It would help us enormously if:

1. You can point us to another license that is strong copyleft and allows unrestricted use of the tool in open source projects only.

• LGPL or one of the other "GPL + linking exception" variants. These are actually GPL with some exceptions for using it in other projects.
• MPL is copyleft per file, which means if a MPL'ed file is included in another project, that file remains MPL. MPL 2.0 is compatible with GPL 3 while the older versions are not. Separate files can be extracted from an MPL'ed project, thus FSF calls this a weak copyleft license.
• EPL is also copyleft per file, but since it is based on MPL 1.0, it's incompatible with GPL. (Because of this, there is actually no legal way of distributing a release of an GPL'ed Erlang application that contains the Erlang/OTP runtime itself.)
• Creative Commons' licenses are not suitable for software as those licenses don't mention anything about source code. See this topic in their FAQ.

GPL has been discussed on erlang-questions multiple times over the years. Some pointers:

• "The Joy of Licenses" http://erlang.org/pipermail/erlang-questions/2001-May/003229.html
• "GNU GPL, MIT, BSD and compatibility" http://erlang.org/pipermail/erlang-questions/2008-April/034326.html
• "GPL and others licenses" http://erlang.org/pipermail/erlang-questions/2014-November/081803.html

... and finally the disclaimer: I'm not a lawyer! :-)

[zuiderkwast]

If you want to be useful to free software projects but you still want to prevent proprietary (closed source) software to be able to use PropEr you could formulate a linking exception such as this one: https://www.mysql.com/about/legal/licensing/foss-exception/. (I wouldn't list all the acceptable licenses though as this list would never be complete...)

[zkessin]

What would worry me is if someone includes proper into another open source project, and then I use that project in a closed source app. If I am using rebar it will include proper as well which might cause a problem.

[essen]

@kostis From what I understand you were interested in the MPL2 after talking with @benoitc about it. The page https://www.mozilla.org/MPL/2.0/FAQ.html should answer any remaining questions; Q1 and Q2 in particular give a general idea and how it relates to the GPL.

To switch the license you would have to ask all previous contributors if they agree to the switch (you should have their email address in the commit) and if not, remove their contribution from the tree. You would also need to inform at least current opened PR contributors about it. You can just copy what they did for the Erlang license switch.

We can help if needs be.

[vlm]

@kostis, would you please either clarify the license further or create a licensing shop? The current situation makes this project totally worthless for the closed source projects and moves people to https://github.com/krestenkrab/triq or QuickCheck.

[eproxus]

it WILL happen (hopefully) soon

@kostis Any update on this?

[marco-m]

Hello @kostis any news ? :-)

[binarytemple]

Riak has now/about to go opensource. Want to get the community involved and make it accessible to non corporate contributors without quickcheck license. Any update

[hauleth]

@kostis any update? I would love to see PropEr to be licensed as LGPL or MPL2.0.

[hauleth]

Ok, I will bump it again with some answers to @kostis:

You can point us to another license that is strong copyleft and allows unrestricted use of the tool in open source projects only.

But you are aware that if someone create application that is accessible only via internet (ex. web service) then they aren't required to open source it? That is why AGPL license is a thing. There is enormous amount of ways to circumnavigate GPL restrictions, especially as this library is for testing only (for example you can make your test suite "separate project" that will just happen to use PropEr and tested application as the dependencies). So GPL, especially GPLv3 is very restrictive in that matter.

Additionally I have pointed you to license that happen to be good balance between restrictiveness of GPL and it's copyleftness: MPL 2.0. Alternatively LGPL would be suitable choice.

You can elaborate what currently stops you from using PropEr in open source projects (esp. after we add an explicit statement that the GPL v3 restrictions are lifted for open source code bases that use PropEr) and whether the possibility to offer non-GPL licenses for a fee will resolve the issue for all (presumably commercial) closed source projects.

As I already said, there is nothing that prevents companies from using PropEr in their projects as long as they do not distribute the application using GPL-licensed code, which in PropEr case mean almost all projects (as I have described above).

---

So if you want to prevent commercial usage of your code, then you haven't prevented this in any way. You just made it more confusing to open source projects, that do not want to be on GPL, to use it.