py61850 0.0.1__tar.gz → 0.2.0.dev1__tar.gz

py61850-0.2.0.dev1/.gitignore

@@ -0,0 +1,24 @@
+__pycache__/
+*.pyc
+*.egg-info/
+build/
+dist/
+.venv/
+venv/
+.pytest_cache/
+downloads/
+relay_files/
+inventory.csv
+
+# SCL / IED capability files (vendor-supplied, large, not redistributable)
+*.icd
+*.ICD
+*.cid
+*.CID
+*.scd
+*.SCD
+*.iid
+*.IID
+*.sed
+*.SED
+fixtures/ICD/

py61850-0.2.0.dev1/CLA.md

@@ -0,0 +1,75 @@
+# Contributor Licence Agreement
+
+py61850 is dual-licensed: AGPL-3.0-or-later for everyone, plus commercial
+licences sold by the copyright holder (see [COMMERCIAL.md](COMMERCIAL.md)).
+
+That second half only works if the project owns, or is permitted to relicense,
+**every line** in it. A patch contributed under the AGPL alone could never be
+included in a commercially-licensed build — it would have to be stripped out, or
+the whole arrangement collapses. So contributions are accepted only under this
+agreement.
+
+> **This document has not been reviewed by a lawyer.** It follows the shape of
+> the Apache Individual Contributor Licence Agreement, which is widely used and
+> widely understood, but if you are contributing on behalf of an employer, or
+> anything substantial is at stake, have your own counsel read it first.
+
+## Agreement
+
+By submitting a contribution to py61850 (a pull request, a patch, a code
+suggestion in an issue), you agree to the following, for that contribution and
+every future one, unless you say otherwise in writing:
+
+1. **You own what you are giving.** The contribution is your original work, and
+   you have the right to submit it. If your employer has rights to work you
+   produce, you have their permission to contribute it, or they have waived
+   those rights in writing.
+
+2. **Copyright licence.** You grant Guilherme Marini, and recipients of software
+   distributed by him, a perpetual, worldwide, non-exclusive, royalty-free,
+   irrevocable copyright licence to reproduce, prepare derivative works of,
+   publicly display, publicly perform, sublicense and distribute your
+   contribution and such derivative works.
+
+3. **Right to relicense.** You agree that your contribution may be licensed by
+   the copyright holder under **any terms, including proprietary commercial
+   terms**, alongside its release under the AGPL. This is the clause that keeps
+   the commercial channel legally possible.
+
+4. **Patent licence.** You grant the same parties a perpetual, worldwide,
+   non-exclusive, royalty-free, irrevocable patent licence to make, use, sell,
+   offer to sell, import and otherwise transfer your contribution, covering only
+   those patent claims you can license that are necessarily infringed by your
+   contribution alone or by its combination with py61850. If you bring patent
+   litigation alleging that py61850 or a contribution to it infringes a patent,
+   the patent licences granted to you under this agreement end on the day you
+   file.
+
+5. **You keep your copyright.** This agreement grants licences; it does not
+   assign ownership. Your name stays on your work and you remain free to use
+   your own contribution however you like, elsewhere.
+
+6. **No warranty.** You provide your contribution "as is", without warranty of
+   any kind, and you are not obliged to provide support for it.
+
+7. **Third-party material.** If a contribution includes work you do not own —
+   an algorithm transcribed from a paper, code from another project, anything
+   under a separate licence — say so plainly in the pull request, with its
+   source and its licence, marked `[third-party]`. It will be evaluated
+   separately. Do not fold it in silently: a single AGPL-incompatible or
+   unattributed fragment is the kind of thing that has to be found and removed
+   years later, from every release.
+
+## Signing it
+
+Add this line to a commit message in your pull request, with your real name and
+the e-mail address on the commit:
+
+```
+py61850-CLA-1.0 signed-off-by: Your Full Name <you@example.com>
+```
+
+One signature covers all your future contributions to py61850. If you cannot
+agree to these terms, you are still welcome to open issues, report bugs, send
+recorded PDU captures for `tests/fixtures/`, and discuss design — none of that
+requires a CLA.

py61850-0.2.0.dev1/COMMERCIAL.md

@@ -0,0 +1,66 @@
+# Commercial licensing
+
+py61850 is dual-licensed. You may use it under **either**:
+
+1. the **GNU Affero General Public License v3 or later** ([LICENSE](LICENSE)) —
+   free of charge, for any purpose, including commercially; or
+2. a **commercial licence** from the copyright holder, on negotiated terms.
+
+Everything here describes option 2. Nothing on this page changes the AGPL: if
+the AGPL suits you, take it and go — you owe nothing and need not ask.
+
+## Which one do you need?
+
+You can use py61850 under the **AGPL, for free**, if:
+
+- you use it **inside your own organisation** and publish nothing. Internal
+  commissioning tools, engineering scripts, a substation HMI your own staff use
+  — the AGPL's obligations are triggered by conveying software to others, not
+  by using it. A utility running py61850 on its own network owes nothing.
+- you **distribute** software built on it and are willing to release that whole
+  work under the AGPL, source included, to the people you distribute it to.
+- you **host** a service built on it and are willing to offer the complete
+  source of that service to its users (AGPL section 13).
+
+You need a **commercial licence** if:
+
+- you want to **ship a closed-source product** that embeds or imports py61850 —
+  an HMI, a test set, a gateway, a configuration tool, a vendor SCADA package;
+- you want to **run a hosted or SaaS service** built on py61850 without
+  publishing its source to your users;
+- you need it under terms the AGPL does not offer — a warranty, an indemnity,
+  liability limits your own contracts require, or the ability to sublicense.
+
+Selling is allowed under the AGPL. What the AGPL does not allow is keeping the
+source closed. That is the line the commercial licence crosses.
+
+## What a commercial licence covers
+
+Terms are negotiated per case; they typically settle:
+
+- **Scope** — which products, which sites, how many installations or devices.
+- **Fee** — a one-off, an annual subscription, per-installation, or a share of
+  the revenue of the product py61850 goes into.
+- **Duration and updates** — which versions the licence covers, and for how long.
+- **Support** — whether any is included, and at what response time.
+- **Warranty and liability** — the AGPL disclaims both; a commercial agreement
+  can allocate them.
+
+## Getting one
+
+Open an issue at
+<https://github.com/GuilhermeMarini/py61850/issues> saying what you want to
+build, or write to the copyright holder directly:
+
+> **Contact:** _add your licensing e-mail address here before publishing._
+
+Please describe the product, the deployment shape (shipped software, hosted
+service, embedded device) and the rough scale. That is enough for a first
+answer on terms.
+
+## Ownership
+
+The copyright holder is Guilherme Marini, who owns all of py61850 and is
+therefore able to license it under terms other than the AGPL. Contributions are
+accepted under the [CLA](CLA.md) for exactly this reason: code the project does
+not own cannot be included in a commercial licence.

py61850-0.2.0.dev1/CONTRIBUTING.md

@@ -0,0 +1,67 @@
+# Contributing to py61850
+
+Bug reports, recorded PDU captures from real IEDs, and design discussion are
+welcome with no paperwork at all. Code needs one extra step — see *The CLA*
+below, and please read it before you write the patch rather than after.
+
+## Before you open a pull request
+
+py61850 is **dual-licensed** (AGPL-3.0-or-later, plus commercial licences sold
+by the copyright holder — see [COMMERCIAL.md](COMMERCIAL.md)). For that to hold,
+the project has to be able to relicense every line it ships, so **every code
+contribution must be signed off under the [CLA](CLA.md)**:
+
+```
+py61850-CLA-1.0 signed-off-by: Your Full Name <you@example.com>
+```
+
+in a commit message on the pull request. One signature covers everything you
+contribute afterwards. A PR without it cannot be merged, however good the patch
+— not a judgement on the code, just a licence the project cannot grant onward.
+
+Contributions that need **no** CLA: issues, bug reports, feature requests,
+questions, and recorded PDUs for `tests/fixtures/` (data captured from a device,
+not authored code).
+
+## What makes a good patch here
+
+The repository conventions worth knowing before you start; the ones that come
+up most:
+
+- **Standard library only.** No runtime dependencies, ever. That is the reason
+  this library installs on a locked-down engineering laptop, and it is not
+  negotiable without discussion first.
+- **`core/` and `mms/pdu.py` do no I/O.** No sockets, no `open()`. The codec is
+  the same code an MMS *server* runs in the other direction, and code without
+  sockets is testable offline. `mms/client.py` and `osi/cotp.py` are the only
+  places a socket belongs.
+- **`link/`, `goose/`, `sv/` stay out of the `py61850` import graph.** Raw
+  Ethernet needs `CAP_NET_RAW` and Linux; the MMS client must keep installing
+  and running unprivileged on any OS. `tests/unit/test_public_api.py` asserts it.
+- **New service groups are mixins** in `mms/services/`, composed in
+  `mms/client.py` — not subclasses of `MmsClient`, which does not compose past
+  one group.
+- **Errors derive from `Iec61850Error`**, so a caller can catch the whole family
+  at once. Do not raise bare `OSError`/`ValueError` from a new failure path.
+- **The library never prints.** User-facing output belongs in `cli/`.
+- **Tests come with the code.** A codec change belongs in `tests/unit/`; a
+  client change can be driven through the `FakeTransport` in
+  `tests/unit/test_client.py`. The suite opens no sockets and must stay that way.
+- **New source files carry the SPDX header** the existing files carry.
+
+## Verifying before you push
+
+```bash
+python -m unittest discover -s tests -t .        # offline; no relay needed
+python -m compileall -q src tests
+python -c "import py61850 as m; print(m.__all__)"
+```
+
+If a change can only really be confirmed against hardware, add an entry to
+[tests/BENCH.md](tests/BENCH.md) saying what to run and what a pass looks like,
+rather than leaving it implicit.
+
+## Commit messages
+
+Imperative mood ("Add file write service", not "Added"). Concise subject line;
+use the body for the *why* when it is not obvious.