Consider using a more permissive license #29

Open
devinus opened this Issue Apr 2, 2012 · 24 comments

Projects

None yet
@devinus
devinus commented Apr 2, 2012

No description provided.

@blt
blt commented Apr 2, 2012

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

@devinus
devinus commented Apr 2, 2012

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
blt commented Apr 2, 2012

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
devinus commented Apr 2, 2012

@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
blt commented Apr 2, 2012

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
toland commented Apr 3, 2012

+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
Collaborator
kostis commented Apr 4, 2012

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
blt commented Apr 4, 2012
  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
blt commented Jun 24, 2012

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.

@kostis kostis was assigned Feb 28, 2013
@devinus
devinus commented Nov 14, 2013

Is there any chance of this happening?

@kostis
Collaborator
kostis commented Nov 14, 2013

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
devinus commented Nov 14, 2013

@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
devinus commented Nov 14, 2013

@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
essen commented Oct 7, 2014

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

@zkessin
zkessin commented Nov 9, 2014

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
essen commented Dec 14, 2014

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:

... 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
zkessin commented Jan 8, 2015

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
essen commented Jun 18, 2015

@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
vlm commented Aug 3, 2015

@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
eproxus commented Sep 28, 2015

it WILL happen (hopefully) soon

@kostis Any update on this?

@eproxus eproxus referenced this issue in davisp/jiffy Sep 28, 2015
Closed

Use triq instead of proper #80

@tburghart tburghart added a commit to basho/hamcrest-erlang that referenced this issue Jan 17, 2017
@tburghart tburghart Rebar3 is in, Rebar2 is out.
 - Replaces how hamcrest.hrl is generated, see comments in
    priv/build/scripts/generate_include.escript
 - Moved .app to src, where Rebar3 will always find it.
 - Rewrote some specs to make dialyzer happy.
 - Made hamcrest:matchspec non-opaque, because that just doesn't work with a shared record definition.
 - Adds Thumbs support.

At present, tests require QuviQ Erlang QuickCheck, and will be skipped (returning success) if it's not installed.

This commit removes support for PropEr due to its license.
Refer to:
  basho/erlang_protobuffs#19
  manopapad/proper#29

It _may_ be worth supporting Triq at some point:
  https://github.com/krestenkrab/triq
87048bd
@tburghart tburghart added a commit to basho/hamcrest-erlang that referenced this issue Jan 18, 2017
@tburghart tburghart Rebar3 is in, Rebar2 is out.
 - Replaces how hamcrest.hrl is generated, see comments in
    priv/build/scripts/generate_include.escript
 - Moved .app to src, where Rebar3 will always find it.
 - Rewrote some specs to make dialyzer happy.
 - Made hamcrest:matchspec non-opaque, because that just doesn't work with a shared record definition.
 - Adds Thumbs support.

At present, tests require QuviQ Erlang QuickCheck, and will be skipped (returning success) if it's not installed.

This commit removes support for PropEr due to its license.
Refer to:
  basho/erlang_protobuffs#19
  manopapad/proper#29

It _may_ be worth supporting Triq at some point:
  https://github.com/krestenkrab/triq
349c691
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment