And the reason he hasn't made money off it in the last 5-6 years has nothing to do with the license -- it is because sending emails from an API is a very saturated market. From custom remailer apis to built-in provide-your-own-SMTP-server options there are plenty of ways to send email from code and most of them are cheap to free.

I am not sure how this is supposed to start making him money. Doesn't the sticky nature of GPL-like licenses only apply if you redistribute the GPL licensed software alongside your own package or make a derivative?

From the text I'm not sure the idea really is to make the author money. If anything, presumably any code others contribute now will be copyleft, meaning if the patches are integrated and re-distributed by the author he can charge for distribution - but have to distribute under copyleft.

I also wonder how many corporations integrate and redistribute nodemailer; I'm sure there's a few - but I'm guessing most just use nodemailer. Apart from paranoid legal teams, the licence change shouldn't make any difference.

Now, someone distributing a firewall appliance using nodemailer for sending email alerts would have to provide customers with a copy of nodemailer source under copyleft - along with any changes. I still don't see why that would translate to payments to the author.

It does. For example MongoDB is AGPL. BUT if you add nodemailer to your project as a dependency and you link to it GPL will stick. This is why MongoDB's drivers are Apache license but the database itself is AGPL.

So, someone told me that your code need not be GPL but that the combination of your code + a gpled program must be.

IANAL, but this sounded reasonable to me.

The trick is in what constitutes "combination", particularly re. static vs. dynamic linking.

My understanding is that, at least with LGPL, you can have a closed source program distributed with a LGPL shared object/dll (plus license text) that gets loaded dynamically, but I don't think you can do that with GPL proper.

Static linking (IIUC) is right out (for closed source projects).

Not sure if it makes a difference in this case either, however the method is being used successfully by projects like x264, x265, which distribute under GPL, but also offer commercial licenses allowing them to be incorporated into proprietary solutions.

What if you do an on-prem SAS deployment? Think that counts.

So why not just close it and sell it then?

Using a license to extort money from commercial entities who he seems to say use it without paying a dime for it and operating under the guise of open source is... warped in my pov.

I don't begrudge him making phat loot. But if that's the goal open source is not the right avenue imo.

Let the flame war begin but I don't see the point in open sourcing code if you don't want people to use it however they want.

YMMV and probably does.

All copyleft licenses have the same principle; to promote openness. This is explicitly not the same as "use it however they want".

I think the motivation to not have your open source code used in a closed source product that is sold for profit should be obvious.

Also, the motivation seems to be a desire for building a bigger community which gives back its improvements. ZeroMQ for example sticks to LGPL for the very reason - they believe that it is easier to build a community and discourage "dark forks" when software is licensed under GPL-like license. (See http://zeromq.org/area:faq#toc4).

They have tried hard for the last year it relicense zeromq under a much more liberals license, but have had trouble getting all permissions.

Additionally, the requirement for being able to sell a business friendly license, seems to imply that any community code contributions must now assign copyright of the contribution to the project owner (CLA?). Otherwise, wouldn't you then have features locked to the EUPL version? (presumably...I am not familiar with the EUPL at all though)

I want you to benefit from my work only if I also benefit from your work. If you seek an unfair advantage over me, I will not cooperate.

Under a copyleft license you CAN use it however you want. You just are obliged to open source any modification you make to it.

I'm not sure how the "derived works" clause applies to node.js projects using this project.

You're obligated to also distribute sources to changes if you distribute.

You can implement single-image clustering on top of the Linux kernel all you want, and keep your changes - so long as you don't distribute the software. If you do, you must distribute under the gpl.

GPL and LGPL require that users of your software have to be able to relink with their own version of the copyleft code. It's not enough just to provide the source (for compiled languages).

The open source version acts as advertising for the paid version. It also allows programmers to imagine that they will get paid (without even having to do "business stuff" like marketing) and get open source cred at the same time. This rarely works but the other open source business models never work, so it's the leader.

Others have pointed some reasons, but there's also another important one.

Copyleft is a promise to he end-users that - no matter the circumstances - they won't be stuck with whatever they were served, but would be able to maintain or hire someone to maintain. It's not only freedom to adapt and modify the code, but also - when a project is a library - a freedom to not be stuck with ancient bug-ridden insecure builds if there are newer versions.

So if you ask "why copyleft?" think how much abandonware with statically linked libraries (e.g. ancient OpenSSL) you've seen.

That's a pretty uncharitable reading of his reasoning. A better description would be "companies are profiting off my unpaid work without upholding their end of the social bargain, whether that's money or maintainer hours or whatever". A better reading would be that he feels the current situation is unfair, rather than suddenly wanting to monetise.

There's nothing unfair about that situation though. People using open source without giving back, and possibly even making money on it without giving back, is perfectly fine. There's no contract, social or otherwise (aside from the license terms), and the perception that there is a unofficial social contract obligating users to contribute back or even do stuff like just file bugs or interact with the community is actually an impediment to getting people to use open source.

This concept of a social contract misrepresents both the letter and the spirit of open source, including copyleft, and gives people who don't know any better the impression that using open source would obligate to do something beyond just complying with the license (even if it's presented as a matter of etiquette rather than an actual legal obligation).

If anyone's out there writing open source code because they anticipate getting anything in return from anybody, ever, for their efforts, they have misunderstood the spirit of the thing and will most likely be disappointed.

> This concept of a social contract misrepresents both the letter and the spirit of open source, including copyleft

Eh? The GPL is a copyleft license that was made to do just this, both in letter and in spirit. "Getting code back" is its explicit purpose.

> If anyone's out there writing open source code because they anticipate getting anything in return from anybody, ever, for their efforts, they have misunderstood the spirit of the thing and will most likely be disappointed.

Open Source and Free Software are similar but different, and you're conflating the two. Redhat is the canonical example of someone who writes FOSS because they anticipate getting stuff for it. Atlassian also writes specifically open-source stuff; you can inspect it, but you can't use it without paying a license.

And I think you're semantically wrong anyway - if you're writing free software because you're community-minded, then it's not unreasonable to expect some engagement from the community, especially for a popular project. No-one is legally obligated to help you, but at the same time, for so many to use your stuff and so few to kick a little back over so many years is something that a reasonable person could be a bit sour on.

> if you're writing free software because you're community-minded, then it's not unreasonable to expect some engagement from the community

Yes it is. Just because you are 'community-minded' doesn't mean you get that - there is no expectation there unless explicitly warranted.

I guess we have different ideas on what makes a community. When I go to a local community barbeque, I hang out and chat as I graze on the food. Apparently you just silently shovel half the sausages into a knapsack, grab a pitcher of drink, and just fuck off without acknowledging anyone. Hey, the food was free, so why should they expect some social interaction, right? I mean, there wasn't a sign up saying "For every sausage, you must spend 5 minutes chatting", so it's not it's expected (or explicitly warranted), right?

I don't think your analogy works, quite.

Principally, the food is a scarce resource whereas the equivalent to software would be where the community were competing amongst themselves to make a single great sausage; that sausage would be placed on a table by the kerb and people outside would be able to take away as many molecularly identical copies of the sausage as they provided energy to create. The community can socialise amongst themselves and you are free to join in but there is no requirement to do so.

However, maintaining a project over the course of years is not effortless on the part of the provider, as explicitly stated in the article. The problem isn't in the software itself being duplicated, it's in the labour around providing the service.

To continue with the (now tortured) bbq analogy: as the sausages go cold (=software ages), someone has to cook up more fresh ones.

> the community were competing amongst themselves to make a single great sausage

I think a great idea was just born! #sausagecoldwar

> Apparently you just silently shovel...

This poor characterisation of me has nothing to do with the topic, and is just abuse.

There is an expectation at a BBQ, though this differs culturally. There is not such an expectation for FOSS projects, unless explicitlty stated somewhere.

If you want to compare the two; tell me why BBQs are generally not open to anyone, whereas there are few restrictions on FOSS contributors? What are the consumables in a BBQ (food) versus a FOSS project (developer time), and who contributes these in each case?

So, to repeat, "I guess we have different ideas on what makes a community."

> tell me why BBQs are generally not open to anyone

Hence why I specified "local community", not "someone's friend's backyard".

In any case, you're missing the point of the analogy, and extend any analogy and it will fall apart. You're missing the human aspect of FOSS, instead interpreting it as a literal legal case.

And yes, there is expectation in FOSS that others will pitch in and help when your project is extremely popular. ESR, coiner of the 'open source' term we're talking about, explicitly promoted it with the term 'enough eyeballs make all bugs shallow'. How is that not seen as an expectation of kicking back at least some effort?

The issue is the expectation that you will receive contributions, versus obligation on all users to contribute, and I don't think there is any obligation.

ESRs quote praises the OS virtue of allowing source code to be read, it doesn't imply an obligation on all users of FOSS, legal, moral, or otherwise.