[docs] OpenWRT => OpenWrt, removed LEDE

docs/source/backends/openvpn.rst

@@ -7,7 +7,7 @@ configurations.
 Its schema is limited to a subset of the features available in OpenVPN and
 it doesn't recognize interfaces, radios, wireless settings and so on.
 
-The main methods work just like the :doc:`OpenWRT backend
+The main methods work just like the :doc:`OpenWrt backend
 </backends/openwrt>`:
 
     - ``__init__``

docs/source/backends/openwisp.rst

@@ -1,7 +1,7 @@
 OpenWISP 1.x Backend
 ====================
 
-The OpenWISP 1.x Backend is based on the OpenWRT backend, therefore it
+The OpenWISP 1.x Backend is based on the OpenWrt backend, therefore it
 inherits all its features with some differences that are explained in this
 page.
 

docs/source/backends/openwrt.rst

@@ -1,7 +1,7 @@
-OpenWRT Backend
+OpenWrt Backend
 ===============
 
-The ``OpenWrt`` backend allows to generate OpenWRT compatible
+The ``OpenWrt`` backend allows to generate OpenWrt compatible
 configurations.
 
 .. note::
@@ -10,8 +10,7 @@ configurations.
 
     UCI stands for `Unified Configuration Interface
     <https://wiki.openwrt.org/doc/uci>`_ and it is the default
-    configuration system installed on `OpenWRT <http://openwrt.org>`_ and
-    its fork `LEDE <https://www.lede-project.org/>`_.
+    configuration system installed on `OpenWrt <http://openwrt.org>`_.
 
 .. important::
 
@@ -172,7 +171,7 @@ file object with the following file structure:
     /etc/config/network
 
 The configuration archive can then be written to disk, served via HTTP or
-uploaded directly on the OpenWRT router where it can be finally "restored"
+uploaded directly on the OpenWrt router where it can be finally "restored"
 with ``sysupgrade``:
 
 ::
@@ -234,7 +233,7 @@ This method is automatically called when initializing the backend with the
 The argument passed to ``native`` can be a string containing a dump
 obtained via ``uci export``, or a file object (real file or ``BytesIO``
 instance) representing a configuration archive in tar.gz format typically
-used in OpenWRT/LEDE.
+used in OpenWrt.
 
 JSON method
 -----------
@@ -551,7 +550,7 @@ Will be rendered as follows:
 Using different protocols
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-OpenWRT supports many protocols (pppoe, pppoa, pptp, l2tp, ecc) and the
+OpenWrt supports many protocols (pppoe, pppoa, pptp, l2tp, ecc) and the
 list of supported protocols evolves over time.
 
 OpenWISP and netjsonconfig try to stay out of your way by leaving you
@@ -866,7 +865,7 @@ network, usually the LAN bridge:
                 },
             },
             {
-                "name": "lan",  # the bridge will be named br-lan by OpenWRT
+                "name": "lan",  # the bridge will be named br-lan by OpenWrt
                 "type": "bridge",
                 "bridge_members": ["eth0", "wlan0"],
                 "addresses": [{"proto": "dhcp", "family": "ipv4"}],
@@ -908,7 +907,7 @@ Wireless access point with macfilter ACL
 
 The ``OpenWrt`` backend supports a custom NetJSON extension for wireless
 access point interfaces: ``macfilter`` (read more about ``macfilter`` and
-``maclist`` on the `OpenWRT documentation for Wireless configuration
+``maclist`` on the `OpenWrt documentation for Wireless configuration
 <https://wiki.openwrt.org/doc/uci/wireless#common_options>`_).
 
 In the following example we ban two mac addresses from connecting to a
@@ -952,7 +951,7 @@ Wireless access point with roaming (802.11r)
 
 The ``OpenWrt`` backend supports custom NetJSON extensions to support
 (802.11r) in wireless access point interfaces (refer `"Fast BSS transition
-options" section in the OpenWRT documentation for Wireless configuration
+options" section in the OpenWrt documentation for Wireless configuration
 <https://openwrt.org/docs/guide-user/network/wifi/basic#fast_bss_transition_options_80211r>`_).
 
 In the following example we configure roaming options for a wireless
@@ -1238,7 +1237,7 @@ WPA2 Enterprise (802.1x) ap
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The following example shows a typical wireless access point using *WPA2
-Enterprise (802.1x)* security on **OpenWRT**, you can use this type of
+Enterprise (802.1x)* security on **OpenWrt**, you can use this type of
 configuration for networks like `eduroam <https://www.eduroam.org/>`_:
 
 .. code-block:: python
@@ -1385,7 +1384,7 @@ WPA3 Enterprise (802.1x) AP
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The following example shows a typical wireless access point using *WPA3
-Enterprise (802.1x)* security on **OpenWRT**, you can use this type of
+Enterprise (802.1x)* security on **OpenWrt**, you can use this type of
 configuration for networks like `eduroam <https://www.eduroam.org/>`_:
 
 .. code-block:: python
@@ -1790,9 +1789,9 @@ Will be rendered as follows:
 Automatic channel selection example
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-If you need to use the "automatic channel selection" feature of OpenWRT,
+If you need to use the "automatic channel selection" feature of OpenWrt,
 you must set the channel to ``0``. You must also set the ``band`` property
-to tell OpenWRT which band to use (``2g`` for 2.4 Ghz, ``5g`` for 5 GHz,
+to tell OpenWrt which band to use (``2g`` for 2.4 Ghz, ``5g`` for 5 GHz,
 ``6g`` for 6 GHz, ``60g`` for 60 GHz).
 
 The following example sets "automatic channel selection" for two radios,
@@ -2159,7 +2158,7 @@ Will be rendered as follows:
 Overriding or disabling ``vid`` UCI option
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The OpenWRT/LEDE UCI ``vid`` option of ``switch_vlan`` sections is
+The OpenWrt UCI ``vid`` option of ``switch_vlan`` sections is
 automatically inferred from the ``vlan`` number, although it's possible to
 override it or disable it if needed:
 
@@ -2404,7 +2403,7 @@ UCI output:
 Including custom lists
 ----------------------
 
-Under specific circumstances, OpenWRT allows adding configuration options
+Under specific circumstances, OpenWrt allows adding configuration options
 in the form of lists. Many of these UCI options are not defined in the
 *JSON-Schema* of the ``OpenWrt`` backend, but the schema allows adding
 custom properties.

docs/source/backends/wireguard.rst

@@ -6,7 +6,7 @@ The ``WireGuard`` backend allows to generate WireGuard configurations.
 Its schema is limited to a subset of the features available in WireGuard
 and it doesn't recognize interfaces, radios, wireless settings and so on.
 
-The main methods work just like the :doc:`OpenWRT backend
+The main methods work just like the :doc:`OpenWrt backend
 </backends/openwrt>`:
 
 - ``__init__``

docs/source/backends/zerotier.rst

@@ -9,7 +9,7 @@ to manage ZeroTier networks on `Self-hosted ZeroTier controllers
 Its schema is limited to a subset of the features available in ZeroTier
 and it doesn't recognize interfaces, radios, wireless settings and so on.
 
-The main methods work just like the :doc:`OpenWRT backend
+The main methods work just like the :doc:`OpenWrt backend
 </backends/openwrt>`:
 
     - ``__init__``
@@ -437,5 +437,5 @@ Now add ``local_conf`` option to ``/etc/config/zerotier``:
 
 - `ZeroTier Controller Local Configuration
   <https://docs.zerotier.com/zerotier/zerotier.conf/#local-configuration-options>`_
-- `OpenWRT ZeroTier Advance Configuration
+- `OpenWrt ZeroTier Advance Configuration
   <https://openwrt.org/docs/guide-user/services/vpn/zerotier#advanced_configuration>`_

docs/source/general/commandline_utility.rst

@@ -55,7 +55,7 @@ Here's the common use cases explained:
     # generate tar.gz from a NetJSON DeviceConfiguration object and save its output to a file
     netjsonconfig --config config.json --backend openwrt --method generate > config.tar.gz
 
-    # convert an OpenWRT tar.gz to NetJSON and print to standard output (with 4 space indentation)
+    # convert an OpenWrt tar.gz to NetJSON and print to standard output (with 4 space indentation)
     netjsonconfig --native config.tar.gz --backend openwrt --method json -a indent="    "
 
     # use write configuration archive to disk in /tmp/routerA.tar.gz

docs/source/general/goals.rst

@@ -9,7 +9,7 @@ Motivations
 
 Federico Capoano (`@nemesisdesign <https://twitter.com/nemesisdesign>`_)
 has written in detail the motivations that brought us here in a blog post:
-`netjsonconfig: convert NetJSON to OpenWRT UCI
+`netjsonconfig: convert NetJSON to OpenWrt UCI
 <http://nemesisdesign.net/blog/coding/netjsonconfig-convert-netjson-to-openwrt-uci/>`_.
 
 Goals
@@ -33,8 +33,8 @@ this brings many advantages:
 
 Another important goal is to build a tool which is **flexible** and
 **powerful**. We do not want to limit our system to OpenWISP Firmware
-only, we want to be able to control vanilla OpenWRT devices or other
-OpenWRT based devices too.
+only, we want to be able to control vanilla OpenWrt devices or other
+OpenWrt based devices too.
 
 We did this by starting out with the :doc:`OpenWrt backend
 <../backends/openwrt>` first, only afterwards we built the :doc:`OpenWisp

docs/source/index.rst

@@ -26,13 +26,13 @@ it's the official configuration engine of `OpenWISP 2
 
 **netjsonconfig** is a python library that converts `NetJSON
 <http://netjson.org>`_ *DeviceConfiguration* objects into real router
-configurations that can be installed on systems like `OpenWRT
+configurations that can be installed on systems like `OpenWrt
 <http://openwrt.org>`_, or `OpenWisp Firmware
 <https://github.com/openwisp/OpenWISP-Firmware>`_.
 
 Its main features are:
 
-    - `OpenWRT <http://openwrt.org>`_ / `LEDE
+    - `OpenWrt <http://openwrt.org>`_ / `LEDE
       <https://www.lede-project.org/>`_ support
     - `OpenWisp Firmware <https://github.com/openwisp/OpenWISP-Firmware>`_
       support