React Leaflet v3

[PaulLeCam]

An early (alpha) version of React Leaflet v3 is available on npm using the next tag: yarn add react-leaflet@next.
There is still lots to do in terms of testing and documentation but this first version is working so far to run the basic examples.

Among the major changes are:

• Full rewrite based on React Hooks (no more extending Component)
• Replace Flow by TypeScript for type checking
• Drop IE support (Babel config will only target the "last 2 versions" of browsers)
• Switch to the Hippocratic License
• The Map component is replaced by MapContainer, behaving differently
• Event handlers must be attached using the eventHandlers prop rather than on* props, with a similar change for path options and WMS params
• The react-leaflet package only exposes a public API while a new package, @react-leaflet/core, is used to provide the core APIs
• A new documentation website using Docusaurus v2 with live examples, currently published on react-leaflet-v3.now.sh

During the alpha versions cycle there is likely to be breaking changes between releases, these versions are only meant to be used by early adopters and contributors who want to help identify and fix bugs.

If you want to help with this release please try to convert components using v2 APIs to v3 and open issues for bugs or use cases that can't be implemented.
Please keep in mind the breaking changes from v2 are intentional for better stability and compatibility with React or Leaflet, so things that may work in a certain way in v2 do not necessarily work the same way in v3.
Thanks!

[PaulLeCam]

beta 1 released with updated docs: https://react-leaflet-v3.now.sh/

[Lorthiz]

Hey it looks... Cool! 👍
One question in examples section I can't see customization using 'className' or 'styles' is it available in this version? Or it is not available because of Leaflet?

[PaulLeCam]

Yes they are supported on the MapContainer component, as described in the docs: https://react-leaflet-v3.now.sh/docs/api-map#mapcontainer

[Lorthiz]

Sorry I forgot to add 'I can't see customization using 'className' or 'styles' on Marker element` :)
Only thing I found so far is Icon property 'className':

        icon={new Icon({
            iconUrl: MiscUtils.getIconUrl(props.markerInfo.iconUrl),
            // iconSize: [32, 32],
            iconSize: [128, 128],
            popupAnchor: [0, -12],
            className: props.isSelected ? "test" : "normal"
        })}

[PaulLeCam]

Props that don't match options supported by Leaflet are not supported, no.

[Ravelonarivo]

Hi!
Will react-leaflt v3 fix the LayersControl name bug when it should change dynamically?
https://stackoverflow.com/questions/59695520/react-leaflet-layerscontrol-dont-change-name-dynamically

[PaulLeCam]

Please don't hijack this thread with off-topic questions.
What you're asking @Ravelonarivo is the expected beahvior and not a bug, the name prop on LayersControl is not mutable.

[Ravelonarivo]

@PaulLeCam Thanks for the explanation and sorry about the off-topic question.

[bz2]

Thanks @PaulLeCam for all your work on react-leaflet! I've now written code using the Leaflet api directly, and v2, and v3 - this version with hooks is by far the nicest interface. My only reaction so far is needed to use key in a few more places than I expected to get components to update in response to prop changes.

This github issue may not be the preferred place to discuss the next point, so feel free to email me instead.

I urge you not to relicense to the Hippocratic License.

Everything below is my opinion and links to posts I've found interesting. Open Source Licenses and the Ethical Use of Software by @christi3k is a good place to start for a summary of the history and counterargument. Thoughts on the subject of ethical licenses by @ddevault is also helpful.

Copyright law is a poor tool for ethical change

Earlier looks at software ethics through the lens of medicine, First, Do No Harm (2004), or I prefer the take by @glyph Ethics for Programmers: Primum non Nocere (2005) are from the perspective of individual duty for good reason.

Large companies, those that might bid on Pentagon contracts, have the resources to clean room re-implement code and fight multi-year legal battles. Problematic software licenses are not new to them, but they are susceptible to employee pressure. Like a new kind of "technology unions" in 'Big Copyright versus The People' by Martin Skladany .

We can make more difference through individual and collective action at work than by limiting the use of some code.

A software license does not persuade

There is some legal analysis on the drafting by @kemitchell in Skimming Hippocratic License Version 2.0, and in general by @tieguy in Evaluating an ethical license for corporate use. I can't speak for them but get the impression they are both broadly supportive, and that the wording issues they had have been resolved. The core problems Luis Villa raises stand though - most people won't evaluate the license, and those that do will probably just decide they cannot use it.

When you install a package with npm the license is not shown. When I build a project with react-leaflet there is no mention of its license in the bundled javascript code. This means the average developer, and their end users, will have no idea of the license terms. As a piece of advocacy, this makes it entirely pointless.

Okay, so, fix, make the package shout when installed, and include the license as a comment not to be stripped in minification. A responsible developer sees it on the non-free list, grumbles, and uses something else. Even if they have access to a legal department, the likely result is blacklisting.

I don't think we're having a conversation or changing any minds like this.

Limiting use hurt allies

This is not a theoretical concern. The small company I work for lists its services on the gov.uk Digital Marketplace and the UK government has recently announced it plans to "break international law in a specific and limited way". I really don't know what the implications of this are, but would prefer they didn't affect our software licensing. I have almost no input into UK foreign policy, but I have got a voice in what projects we work on as a company.

For an interesting exploration of the extreme see What usage restrictions can we place in a free software license? by @mjg59 but the reality is I have more control through where I spend my time and attention, than ability to get into legal wrangles with end users of my code.

Facebook will continue "hurting people at scale" without ever using Leaflet or this library. I'm going to continue advocating to friends and former colleagues not to work there, and work on using maps to explore how we should reform capitalism, and would appreciate being able to use your code.

[PaulLeCam]

Thanks @PaulLeCam for all your work on react-leaflet! I've now written code using the Leaflet api directly, and v2, and v3 - this version with hooks is by far the nicest interface. My only reaction so far is needed to use key in a few more places than I expected to get components to update in response to prop changes.

Thanks! I'll try to reply to your following comments here.

We can make more difference through individual and collective action at work than by limiting the use of some code.

I don't see how this is related, if anything it seems to me these are complementary approaches rather than opposing ones.

The core problems Luis Villa raises stand though - most people won't evaluate the license, and those that do will probably just decide they cannot use it.

When you install a package with npm the license is not shown. When I build a project with react-leaflet there is no mention of its license in the bundled javascript code. This means the average developer, and their end users, will have no idea of the license terms. As a piece of advocacy, this makes it entirely pointless.

Just because something is available on npm or the Internet in general means people can freely use, that's why copyright laws exist.
If the "average developer" ignores these laws, it's a problem for them and/or the companies that employ them, well beyond the scope of this library.

I don't think we're having a conversation or changing any minds like this.

I don't think we're having a conversion or changing any minds by not making any change either, but the fact you're commenting here seems to show it can a least help start a conversation.

This is not a theoretical concern. The small company I work for lists its services on the gov.uk Digital Marketplace and the UK government has recently announced it plans to "break international law in a specific and limited way". I really don't know what the implications of this are, but would prefer they didn't affect our software licensing. I have almost no input into UK foreign policy, but I have got a voice in what projects we work on as a company.

The fact it's not a theoretical concern is exactly the point. People and projects violating human rights are not allowed to use this library.

Facebook will continue "hurting people at scale" without ever using Leaflet or this library. I'm going to continue advocating to friends and former colleagues not to work there, and work on using maps to explore how we should reform capitalism, and would appreciate being able to use your code.

For sure this change is not going to affect big tech companies. It's also not going to affect you or your projects unless they're violating human rights.
The goal with this license change is simply that I don't want to be complicit even in a very remote way with the actions of people violating human rights. For sure it's not going to prevent them from doing so, but that doesn't mean I have to make it easier for them.

[glyph]

It's also not going to affect you or your projects unless they're violating human rights.

This is a misunderstanding of how licensing restrictions work, and how they interact with vetting processes at large organizations like governments and corporations.

I'm not a lawyer but I've worked with lawyers on evaluating licenses on a number of occasions. The question is never, ever "are we going to violate human rights" but rather "do we trust that all copyright holders who might declare a human rights violation as a cause of action for a copyright infringement claim will always act in good faith when evaluating the actions of ourselves, our partners, our customers, and our suppliers as 'human rights violations', not only as direct representations to a court but also when contemplating legal strategies in unrelated matters, not only on their own behalf but also when acting on behalf of our competitors that they're contracted to". i.e. "Are we absolutely sure that $EVIL_COMPETITOR_X will never offer one of Leaflet's authors (or one of their contemporaneous employers, who they may never have properly obtained a release from) an obscene amount of money for the rights to tie us up in court forever?". The answer to this question is always, always "no". No competent lawyer will trust a license like this (edit: this was unfair hyperbole; see my comment below), even if they are absolutely 100% convinced that their customers' human rights record is completely, perfectly spotless.

For example, you can easily construct dozens of specious claims that the very act of using a computer is, at the very least, facilitating or abetting a violation of human rights. Did you write Leaflet itself on a computer completely free of conflict minerals? (I'm asking this question rhetorically but if you really have such a thing I'd love to know where to buy one.)

Even if you did, did you use a special, second Internet for interacting with Github which didn't use any in its construction? Or that wasn't substantially built by the US Department of Defense for use in war?

I'm sure I could find at least a couple of lawyers who could argue that 'buying coltan to fuel wars in the DRC is a human rights violation' is at least a colorable claim. Maybe not to win a case, but enough to incur hilarious and terrible levels of litigation fees. (There's no such thing as an anti-SLAPP law for copyright claims.)

What you're doing here is you're setting up a version of an asshole filter. Rather than removing human rights violators from the user-base of your library, you remove users who pay enough attention to license terms to make a good-faith effort to follow and honor them; it's not "anyone who violates human rights", it's "anyone with a lawyer".

This also affects smaller players much more than big ones. Smaller, independent software shops that do contracting are inherently less rigorous than big corporations about checking license terms. Standard contracting terms almost inevitably mean that they're the ones that end up holding the bag if the license crops up as a problem during a vendor review, not the big client.

I don't want to be complicit even in a very remote way with the actions of people violating human rights.

I wish you luck in your progress towards this goal; I've written the above analysis because I think that attempting to do this with software licenses is counterproductive, but I would definitely rather be wrong about all of this.

[PaulLeCam]

I'm well aware that this change will restrict usage of this library for companies due to the uncertainty.
These companies could also be kicked out of iOS without recourse if Apple decided to, or virtually any technology or market if some politician decided so, it's up to them to evaluate the technologies they use and the risks associated.

My goal here is not to prevent small tech shops from using this library just to display a map on their customers website, but rather to explicitly prevent usage for military or related applications.
I think there is a big difference between "using the Internet even though its creation was supported by the DoD", to paraphrase your argument, and for which I can't do anything about, and actually facilitating the use of some technologies for reprehensible use cases, in which case I can at least refuse that my work on this library be used for.

[kemitchell]

I agree that the way potential users assess and manage licenses is also important to think about, beyond what the license itself says. But I strongly disagree with @glyph's blanket statements about what any competent lawyer would say or do, and have serious doubts about some of the more specific analysis he channeled, though less of it than I'd expect in your average GitHub comment.

I remember learning as a boy that you should always think through a numerical algorithm with inputs of 0, 1, -1, MAX_INT, and MIN_INT. When it comes to thinking through licenses, it's worth asking whether arguments would make sense about AGPL, GPL, Creative Commons NonCommercial, or MIT, as well.

I'm not particularly fond of Hippocratic 2's implementation, as has been pointed out. But it's hardly the first "ethical" or ethically motivated license. GPL is by far the most famous. Whether those earlier licenses, or any of the new ones, have contributed toward their author's or anyone else's goals, or could today or next year, is very much open to interpretation. Was GPL a failure, because it failed to achieve universal software freedom? Or has it succeed, not as the tool for promoting "freedom", but one of them?

I'm not here representing anyone, or to give professional advice, but I'd also point out here what's so often missed in discussions about particular projects: @PaulLeCam is evidently pretty easy to reach, and responsive. When that's the case, it's often possible to do one-off deals or exceptions.

[glyph]

But I strongly disagree with @glyph's blanket statements about what any competent lawyer would say or do

I apologize for that phrasing. While I stand by a lot of the general analysis that you disagree with — which is, I should stress, about the psychology of risk in large organizations, and the impact of the analysis driven by that psychology on the rest of the industry, and only peripherally about IP law — "no competent lawyer" was a turn of phrase that is both unfair and doesn't really comport with what I believe.

What I meant was closer to this: I would personally be very surprised if a corporate IP lawyer evaluating this license for broad usage in any kind of large organization were to approve it. There are a number of situations where the risk/reward might be substantially different, and that is in some sense a "narrow" kind of analysis.

I'll strike it out in my original comment.

[kemitchell]

@glyph's coming from an honest place. No doubts about that on my end at all.

He's also right that especially large companies do ban some standardized licenses by policy. So it's gone with AGPL and CC-BY-NC and even GPLv2&3. Whether that's malfunction or validation is a matter of diverging opinion. Cue the JSON License IBM Crockford story.

[bz2]

@PaulLeCam thank you for responding (and thanks the atted for chipping in).

I have various reactions, but not much novel to add. So instead, will try be constructive.

Rather than changing the license, why not use the new documentation (which looks great by the way), to make the argument for ethical use of your code. Maps are a great tool to expose lies and injustice of all kinds^{1 2 3 4 5 6}, and developers are going to be reading the docs much more attentively than the license terms.

That could result in reaching some people who aren't already persuaded, and that independent developers can still build platforms that serve their customers and users without taking on an unsatisfiable legal burden. I am happy to help out.

[PaulLeCam]

The goal is not to expose or persuade anyone, it's to prevent people from using this library for specific purposes.

It has to be a constraint or "legal burden" as you put it, or it wouldn't change anything.
I highly doubt IBM's lawyers would have bothered contacting Crockford if his "The Software should be used for Good, not Evil." sentence had been written in his library's documentation rather than license.

[PaulLeCam]

v3 is now released.
Thanks to everyone who helped test it and fix issues for this release!

[sfgoncalves777]

congratulations, you managed to worsen what was already good