Build/Install instructions are in the source code (of course)!

Posted Nov 4, 2024 20:12 UTC (Mon) by ossguy (subscriber, #82918)
In reply to: “Offer for Source” is quite prominent on the box and also printed on PCB! by bkuhn
Parent article: The OpenWrt One system

The unit reviewed above is a Test Run unit, so there are several changes you can expect in the final version, including a bundled power adapter, and no need to reflash the device — it will ship with the standard image (including LuCI) you'd expect from OpenWrt. Also, we'll fix typos on the box (such as the missing newline).

I did also see this note in the article:

A nice tutorial on how to build a custom image for this device would be welcome.

Probably that was written before Jon corrected his error regarding the offer for source code. The source code (which is downloadable today — but we'll of course send it to you in a “medium customarily used for software interchange” by mail if you prefer) includes all the instructions needed to make modifications to the image and install those modifications on the device (i.e., it includes all “the scripts used to control compilation and installation of the executable[s]” — as all compliant source releases must when a device uses copylefted programs). Specifically, you will find these in the how_to_compile_and_install.txt file. Of course, you can also build and modify OpenWrt using the usual repositories instead — that is to say, a stock build of SNAPSHOT (or the upcoming release) will also work fine.

Lastly, regardless of the sticker price you pay, a US$10 donation will go to the OpenWrt earmarked fund at Software Freedom Conservancy for every unit sold.

to post comments

Prominent notices

Posted Nov 5, 2024 19:59 UTC (Tue) by comex (subscriber, #71521) [Link] (11 responses)

I notice that the tarballs don't have .git directories and so don't encode Git history. Given that, how are you complying with GPLv2 section 2a's requirement to "cause the modified files to carry prominent notices stating that you changed the files and the date of any change"?

I am partly trolling, partly serious. I'm trolling in the sense I'm well aware that this requirement is routinely ignored across all the licenses it appears in. I'm serious in the sense that, if you're making a point of dotting i's and crossing t's regarding license compliance, I feel like you ought to have an answer to this question.

I'm also aware that the Git history is publicly available on GitHub. The tarballs are even labeled with the corresponding commit hashes. So for all practical purposes, nothing is missing. But the page you linked, https://one.openwrt.org/sources/, seems to be portraying the tarballs as independently satisfying the GPL's source distribution requirements, so my question is about how they do so, not about whether the requirements are satisfied some other way.

I'm mainly referring to the top-level scripts and other OpenWrt-specific code that is licensed under GPLv2, not the third-party projects whose tarballs are included. OpenWrt does not appear to use copyright assignment, but instead relies on a peer-to-peer licensing model, judging by the top-level COPYING file's statement that "All contributions to OpenWrt are subject to this COPYING file." In other words, each contributor who submits a change is distributing a "modified version" to everyone else, triggering the requirement for "prominent notices". There are no such notices "carr[ied]" in the files themselves, as the license seems to have originally envisioned. But I've seen it argued that Git history counts as sufficient notice, since it indicates who changed which files and when. However, that wouldn't apply to tarballs that lack Git history.

Can you get away without distributing history because the original changes would have been submitted with history, and the later redistribution into a tarball is a separate event?

(As for third-party projects, I see that OpenWrt-specific changes are already cleanly separated out into patch files, and some of the patch files contain From: and Date: lines. However, others don't. The tarball's date metadata doesn't help here: it lists the same date for all files, presumably the date when the tarball was created as opposed to when the patches were written.)

GPLv2§2(a) does not say what you think it says

Posted Nov 5, 2024 21:17 UTC (Tue) by bkuhn (subscriber, #58642) [Link] (10 responses)

> I am … trolling

🙄 … Yes, you are. I wrote on this issue extensively 13 years ago:

https://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

The text of GPLv2 hasn't changed in the meantime — to my knowledge.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 10:33 UTC (Wed) by paulj (subscriber, #341) [Link] (9 responses)

The text of the GPLv2 can stay unchanged, but the practical requirements of meeting it can easily change, given the GPLv2 refers to customary practice wrt software interchange.

The customary practices of the software industry have changed greatly since the GPL was written.

Personally, I'd love to see a court come along and kick the backside of the various people who insist that the GPL distribution requirements are set in stone, and hence a tarball suffice. It's as daft as arguing that because mailing out tape with a tar file was acceptable in the 80s that it's acceptable today.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 12:34 UTC (Wed) by pizza (subscriber, #46) [Link] (5 responses)

> Personally, I'd love to see a court come along and kick the backside of the various people who insist that the GPL distribution requirements are set in stone, and hence a tarball suffice.

The tarball _is_ the "complete corresponding source code."

The git commit history is _not_.

End of story.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 12:37 UTC (Wed) by pizza (subscriber, #46) [Link]

Adding to this, the "git history" can _easily_ contain things that (a) the organization does not have the legal right to redistribute, and (b) has nothing to do with the GPLv2 software in question.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 13:14 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

The tarball is not, these days, the source code in the form preferred for making modifications. If you have:

1. A git repo, that you and your organisation use for working on

2. A tarball made from 1 with git archive

And you try tell me that the /latter/ is the preferred form for you or anyone else, then I say you are simply lying (possibly cause your business model depends on it).

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 13:31 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> And you try tell me that the /latter/ is the preferred form for you or anyone else, then I say you are simply lying (possibly cause your business model depends on it).

I'm going to take the FSF's word over yours.

Or are you accusing the FSF of violating their own licenses, possibly because "their business model" depends on it?

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 13:43 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

If you have a reference to somewhere where the FSF defines source code as something different to the "preferred form of the work for modifications", I'd be interested to read that. Regardless, the term "source code" is explicitly defined in that way in the GPL text itself - if there's some pronouncement on some obscure web page somewhere, that probably doesn't matter.

Further, again, it's explicitly defined in a way that allows the meaning to be context (including temporal) specific.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 16:04 UTC (Wed) by pizza (subscriber, #46) [Link]

I can comply with your interpretation by supplying at tarball that contains a git repo with a single commit -- The complete corresponding source code to the binary I'm distributing. I am under no obligation to supply the source code to binaries I did not distribute, nor am I under any obligation to distribute any/all prior versions of the source code. [1] [2]

...Or are you arguing that everyone should be forced to publish every private intermediate draft or edit, even if there was no external distribution of anything (binaries or source)? Is git squashing and rebasing now verboten?

[1] I make a minor change to Linux to support my hardware. Should I also have to distribute all 3GB of Linux's upstream git history? What about upstream's pre-git history all the way back to 1991? If the answer is different, why,? What's the cutoff? one version? Five versions? One year of history? five years of history? What if I don't use *your* preferred VCS at all? Can I comply by supplying a SoS, Perforce, or Bitkeeper repository (that you may not be able to legally access because you worked on a competing VCS in violation of the Bitkeeper license)?
[2] Overly pedantic folks can argue that one needs to include "prominent notices" saying the date of your modifications (GPLv3 5(a) ) -- But you don't have to enumerate your specific changes, and the "date" can just be when you publicly published them in the modified work. Still, you can achieve both by your tarball'd git repo having two commits; the first being the unmodified upstream source code, and the second containing all of your changes.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 15:55 UTC (Wed) by ballombe (subscriber, #9523) [Link]

> The customary practices of the software industry have changed greatly since the GPL was written.

SCCS (1973) <https://en.wikipedia.org/wiki/Source_Code_Control_System>
RCS (1982) <https://en.wikipedia.org/wiki/Revision_Control_System>
CVS (1986) <https://en.wikipedia.org/wiki/Concurrent_Versions_System>
GPLv2 (1991)

So at the time the GPL v2 was drafted, version control system were already in use by professional developers,
including by the GNU project (which released RCS as GPLv1 before GLPv2 was published).

GPLv2§2(a) does not say what you think it says

Posted Nov 7, 2024 12:49 UTC (Thu) by bkuhn (subscriber, #58642) [Link]

> The text of the GPLv2 can stay unchanged, but the practical requirements of meeting it can easily change, given the GPLv2 refers to customary practice wrt software interchange.

GPLv2 refers to “customarily” only in GPLv2§3(a). Indeed …
…
> It's as daft as arguing that because mailing out tape with a tar file was acceptable in the 80s that it's acceptable today.

… no one (particularly, not me) was arguing in this thread that 8mm tape (or other software delivery methods common in the 1980s and 1990s) are still “customarily used for software interchange”.

We were talking about GPLv2§2(a), not GPLv2§3(a).

And, FWIW, I've been doing GPL enforcement and compliance as my primary work activity since 1997, and I have never seen anyone argue before that you have to interpret GPLv2§2(a) using the language in GPLv2§3(a). I'm open-minded to it, as it is common for one part of an agreement to influence interpretation of other parts, but there are lot of dots to connect to make a successful argument that the wording of GPLv2§3(a) somehow influences GPLv2§2(a) — and you've not connected those dots.

GPLv2§2(a) does not say what you think it says

Posted Jan 19, 2025 9:55 UTC (Sun) by Wol (subscriber, #4433) [Link]

> Personally, I'd love to see a court come along and kick the backside of the various people who insist that the GPL distribution requirements are set in stone, and hence a tarball suffice.

Well, If I can't be assed to use a VCS (some people don't), and my standard backup practice is a tarball (ie I'm a dinosaur, which is true but in my case not THAT true), then a tarball is the only choice.

The end user does not get to dictate to the developer what working practices they use. If the developer says "here is a copy of my working directory as backed up when I gave you the binary", then that's what you get!

And if the developer says "I've only got mobile pay-as-you-go internet and posting a CD is cheaper" then you have to negotiate a price for sending it by email or whatever.

At the end of the day, pretty much the only come-back the user has against the developer is "you're not allowed to treat ME DIFFERENTLY with the INTENT of causing pain".

Cheers,
Wol