开云体育

Can you change the sources for the better and build the firmware?
I think no!
But to scratch all the masters with a yashchyk! :)

I have watched with admiration the work being done to accommodate requests
for improvements and generally push the firmware envelope for the nanoVNA.
Out of common courtesy, I would never grab the work of another software
developer without express permission to do so whether it is "legal" or not.
For those that think they are left out on a limb without repository access
to their installed firmware, they can reflash from what they can find in
current repositories.
Apparently no good deed goes unpunished...

Why copy the repository? On this forum, two people could compile the
firmware from the source!

Now they are not here! Who's getting better?

On Fri, Aug 7, 2020 at 06:35 AM, Hasan Schiers N0AN wrote:

I didn't see a NanoVNA-F there, does he carry them?
===============================================
Hasan,
R&L currently only carry hugen's product line.

- Herb

On 8/7/20 1:51 AM, Erik Kaashoek wrote:

On Thu, Aug 6, 2020 at 03:21 PM, Roger Need wrote:

From what I read some users just wanted edy555's code licensed using

GPLv3 to

be released in accordance with the terms of the license which says

modified

source code is to be included with ANY firmware release that is made

available

to others. The license terms are clear and it is not fair to the

original

author (edy555), other contributors or in the spirit of "open software"

to do

otherwise. It would not have been that difficult to put the modified

source in

with their firmware in a zip or rar file. That would have met the

license

terms and avoided all the controversy

As someone that is actively maintaining various GPLv3 SW packages I'd

like to add some words.

The issue seems to be foremost a matter of tone.
Nobody here will disagree that GPLv3 SW comes with certain obligations.

But at the same time someone contributing may feel uncertain about how in a
transitional state the code may look and does not want to publish every
time a small fix has been made because that person wants to publish well
written, well documented source. So sometimes the development (and testing)
goes through a number of iterations before the outcome is deemed stable and
the code is published. Legally this may not be allowed but nobody wants the
alternative, e.g. no wider testing of beta releases and taking someone to
court on this is unrealistic.

Now what happens when suddenly in the midst of such a high energy

updating sequence someone starts to DEMAND every iteration MUST have
published source. It has happened to me. I did not like the tone, it felt
like an insult given all the effort I was putting into this and I did
considered to delete everything and stop. People that contribute to the
community are motivated by the recognition they get. Someone suddenly
DEMANDING something is a very strong demotivator.

All people in this group that where releasing new FW's did publish (at

least as soon as the source became stable, sometimes more often) code to
github. Nobody ever stated they did not intend to do this.

So I'd kindly ask people not to DEMAND something but, while voicing

respect for the huge contribution, kindly request when the next update of
the github repository can be expected.

I agree...

Most software development of this type is episodic and goes in bursts.
It's perfectly reasonable (if not precisely according to the letter of
the law, regulation, contract) to have things in a state of flux due to
debugging and push out the artifacts towards the end of the burst.

But this points up a defect in the GPL vis a vis modern software
development process.

A collaborative build/test environment benefits from the use of (semi)
public repositories for intermediate builds - especially for the alpha
and beta testers, who are interested in *using* but not modifying the
software. Perhaps the progenitors of GPL (FSF?) should contemplate this
model of operation.I fully recognize that some of the leading advocates
of free software (both as in beer and speech) aren't necessarily
interested in being reasonable - they're trying to push a cultural change.

Not everyone runs a "commit to the repo before every test build/compile"
type development operation for a variety of reasons.

And even if you did, you'd wind up with people having trouble with the
build because of environment differences - which libraries do you have,
which version of glibc, etc.

This is true even in professional environments. I spent a week getting
NEC4.2 to compile on a Mac, even with decent instructions from someone
who had done it before. Ditto when moving the code from one
supercomputer to another (because the underlying environments were
*slightly* different).

I have also spent weeks getting RTEMS ( a great open source RTOS)
working on a new development machine - so open source is no panacea
there either.

I am *quite sure* that DiSlord and OneOfEleven have their hands full
just making the firmware work and aren't interested in supporting people
trying to get the cross tools running, etc. Getting NanoVNA-saver
working, which is in Python, which is pretty good for cross platform
support, took some dozen or so messages back and forth among forum members.

--
And I also agree that there are people who demand stuff: I've
experienced it, told them I'm not going to, and got flamed.

I suspect that if you DID have a build process that pushed everything to
a repo before builds, but you used, say, cvs, or sourcesafe, then people
would gripe about you not using git. (or, in the case of SourceSafe,
gripe about using a non GPL tool to develop GPL software, which is
somehow anathema by their beliefs).

In any group that is sufficiently large, there are certain to be jerks.