Open halite to the community

[mabar]

PHP 7.2 is behind the doors and many of us will switch to sodium as our encryption library. It is not easy to use so we will look for a higher level interface. Halite is currently only one doing this job and it is doing it really well. But is unusable for majority of projects because of license.
That majority cannot use GPLv3 licensed libraries. Please, give us choice to use another license by default instead of offering commercial licenses. We cannot rely on just a chance of obtaining non-gpl license.
We need to know there is a encryption library we can use everytime with all our projects. And if halite is not library which allow it, community will create alternatives. Why we should do it when perfect library currently exists?

[paragonie-scott]

I'm going to set aside my disagreement with the implications of the issue title for a moment and focus on the core proposal.

---

That majority cannot use GPLv3 licensed libraries. Please, give us choice to use another license by default instead of offering commercial licenses. We cannot rely on just a chance of obtaining non-gpl license.

Sure, we're not married to GPL in particular. All we need is another license that contains the following properties:

1. Discourages use of Halite in code obfuscation technologies (which consequently hurt the community by making less PHP code open source).
2. Incentivizes companies to actually pay us if they're going to use our work.
   • Too-permissive licenses like MIT or BSD do not accomplish this at all, and Paragon Initiative Enterprises is a for-profit company so that outcome is not acceptable to us.
   • The "donation" model for open source is not viable.
3. Is recognized by the Open Source Initiatve, not an ad-hoc creation of people with no legal background.

Those are our requirements. I'm not a lawyer, so I don't know if e.g. Apache License will work in its stead. If a suitable replacement is found, I'll spot check it for sanity then pass it to our company's legal counsel for verification before committing to any changes.

I don't want it to be the case that the cryptography libraries I develop are turned into weapons against user privacy or freedom. I also don't want it to be the case that we have to shut down our operations because we gave too much away for free.

That's where I stand on this matter.

---

Back to the implications

Your title is "Open halite to the community" and you said "[The majority of the PHP community] cannot use GPLv3 licensed libraries." I disagree with these premises:

1. Halite is open to the community. The source code is right there.
2. The only thing preventing people from using GPLv3 libraries isn't anything we're doing, it's that their employers tell them they cannot use GPLv3 code.
   • This is only a concern for companies if they want to drop binary blobs onto their customer's computers and forbid them from studying it. PHP scripts are inherently open source, so complying with the GPL is almost trivial. You'd have to go out of your way to use something like ionCube to violate it outright.
   • This is, consequently, only a concern for other open source developers who want to cave to the pressure that abusive companies exert on the community. The story usually goes, "Our code has to be MIT/BSD/etc. for companies to use it, and companies have to use it for us to grow our consulting business." But, honestly, how much money do you think we've made over the years from all of our MIT/BSD-licensed software libraries that demonstrably make their code more secure? I doubt we're exceptionally unappreciated here.

It's very tempting to buy into a "GPL locks code away from the community" narrative. And there are aspects of the GPL I dislike (the viral licensing clause being a big one, which feels like an inelegant, shotgun solution to prevent clever loopholes that benefit the worst offenders in our industry).

So, in sum: Sure, I'm open to alternative licenses, but if anyone's idea of "opening Halite to the community" means surrendering our work to the hands of code obfuscation charlatans, cheapskate free riding companies, outright bullies, or bleeding ourselves dry, they will not be happy with the result of this discussion.

So, what have you got?

[mabar]

Thank you for answer. I must agree it's impossible to gain money only with donations. But I think this is what should we expect when developing open source.
I like model which I found in community around Nette framework. We see open source as something what should show world we are doing good work and others should use it. We are building our reputation throught open source. So we don't directly gain money on our software. But code itself is not everything. We are gaining money throught learning courses and code audits.
Isn't that model suitable for you too?
Even if the documentation and api is clear, people still need someone who learns them. Plus with courses you spread awareness about your library. You would find out that there are many who would use your code, they just did not find it.

[paragonie-scott]

But I think this is what should we expect when developing open source.

I disagree, and I'm not sure I like the implications of this statement either.

I worry that this expectation can lead to supporting toxic environments. There are many valid reasons to develop open source software that don't boil down to a "Vow of Poverty Cyberpunk" lifestyle.

I like model which I found in community around Nette framework. We see open source as something what should show world we are doing good work and others should use it. We are building our reputation throught open source. So we don't directly gain money on our software. But code itself is not everything. We are gaining money throught learning courses and code audits.

That sounds like it works for you, and that's a perfectly valid way to solve this problem. I'd caution against one-size-fits-all reasoning.

Even if the documentation and api is clear, people still need someone who learns them. Plus with courses you spread awareness about your library. You would find out that there are many who would use your code, they just did not find it.

It might work, but creating courses that people actually find valuable requires:

• Time, which I don't have a lot to spare these days.
• Money; the acquisition thereof is currently eating most of my spare time.
• A background in education, which I do not have, and do not have the time to acquire.

The code audits we typically perform are on bespoke web applications, not on software that integrates our libraries.

[carnage]

I'm really not sure what the issue is with the GPLv3 especially for the majority of PHP developments. From my experience, most are bespoke pieces of software which either power a business or serve their customers; neither of which would trigger the conveying software part of the GPLv3.

If you have an issue with the GPLv3 for other reasons, perhaps the solution is to pay Paragonie to license the code under a commercial license which is more to your tastes. This has the added bonus of supporting the development of the library for the community.

Here is a good primer on the GPLv3 protections and why they are important: https://www.gnu.org/licenses/quick-guide-gplv3.en.html

[sstok]

Frameworks usually benefit a permissive license as the creator(s) use the framework itself for products they sell; Sylius, Symfony, Zend Framework, to name a few.

The risk of loosing money on private forks is to minimum for them as they still need the framework to develop and sell there services. And therefor they can develop it for "free".

However most projects like Drupal, Wordpress, the Linux kernel (hello 👋 ) can only exist when they remain free for everyone. Sure, there are commercial services outside of the core project, but they don't have anymore power then anyone else.

In the case of projects like Halite, Airship, and Launchpad the GPL license is used to provide a good quality product for free (for everyone), but those who "need" more can get the source by paying for a special license that grants them exclusive privileges.

Normally I find this way of making money (on others work) a little doubtful (in lack of better words). ownCloud, MySQL, and many others use(d) this to make money with the work of it's contributors, however because contributors are required to sign a Contributor License Agreement (CLA) the company behind the product fully owns everything!

ownCloud even use(d) AGPL which requires that all source code is always "accessible" for everyone that uses the software. If you wanted to develop/use a commercial plug-in you were forced to pay for the complete version. Eventually almost all core developers left, and created a fork which didn't have this dual license.

The main problem I have with this (AGPL) profit model is that is goes completely against the philosophy of free software. If you release something under the GPL license we all share the freedom and limitations. But by using a CLA the contributors basically are working for nothing while the company reaps the benefits...

Having said all this, Halite is an exception to this rule as it's so advanced only real experts are able to provide big contributions 😄 so nobody is hurt here.

I think biggest problem with the current license is usage in combined work (Apache 2.0 compatibility for example) but as PHP doesn't require compilation this problem is rather minimum. If you use Composer to install everything you shouldn't run into this problem.

Maybe instead of using GPL, LGPL is a better choice (as this in fact a library)?
For a big project I choice the MPL 2.0 license is has the same legal protections as the GPL license but only covers the code itself (per file and not distribution).

To be clear I do appreciate the hard work of Paragon IE and thank them for there amazing work 😉

[paragonie-scott]

Maybe instead of using GPL, LGPL is a better choice (as this in fact a library)?
For a big project I choice the MPL 2.0 license is has the same legal protections as the GPL license but only covers the code itself (per file and not distribution).

MPL and LGPL both seem appropriate. I'm going to inquire if something like "GPL for DRM products, LGPL/MPL for everything else" is a viable option.

[paragonie-scott]

The verdict is: "No, that would be stupid." (The whole DRM software gets the more restrictive license thing.)

But moving to MPL seems saner than LGPL.

[paragonie-scott]

Halite v4.0.1 and newer are available under MPL-2.0. The licensing change will not be backported to earlier branches. Consider this an incentive to not run older versions of PHP. ;)