directory-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-linux-libre] license of 'yggdrasil' software


From: bill-auger
Subject: Re: [GNU-linux-libre] license of 'yggdrasil' software
Date: Wed, 15 Mar 2023 12:55:48 -0400

On Wed, 15 Mar 2023 00:39:13 -0300 Alexandre wrote:
> opinion on the matter that was not backed by this kind of legal counsel
> wouldn't move us any further on the matter, would it?

youre right - it would help, only if the advice was indeed
well-informed - surely, people (myself included) assume that the
FSF is well-informed WRT the GPL, and the implications of
dismantling sections of it - i would hope that authors who
choose to modify the GPL, would consult with the FSF before
doing so - so i assumed that the FSF has been asked such
questions in the past, and would have some prepared advice for
the common modifications


On Wed, 15 Mar 2023 00:39:13 -0300 Alexandre wrote:
> it was often the case that
> issues that people found confusing were transparent to me.  Maybe this
> is one of those cases?

the 'yggdrasil' license is not so confusing - the 'nmap' is more
hairy though - most licenses can be evaluated simply by
contrasting it to the four freedoms - the 'yggdrasil' license
does not prevent anyone from sharing CCS - that option remains;
so freedom #1 is satisfied

thanks for your thoughtful answers Alexandre - i am patient - i
mostly just wanted to start a discussion - and youre right, i
probably chose the wrong week - i was hoping that someone on the
FSD team would know something about 'yggdrasil', so that i could
join the friday meeting on IRC and provoke movement on the FSD
entry


On Wed, 15 Mar 2023 00:39:13 -0300 Alexandre wrote:
> > the FSD and FSDG should never be in conflict
>
> I'm not sure what you mean here.  There are cases in which a piece of
> software may qualify as Free Software without meeting the requirements
> of the FSDG, and those are intended to be so.  Is this the sort of
> conflict you meant?  Or something else?

no, im aware of those differences - the FSD requirements are a
proper sub-set of the FSDG requirements; so it is a one-way
implication - software which does not satisfy the FSD
requirements, necessarily can not satisfy the stricter FSDG -
conversely, software which satisfies the FSDG, necessarily
satisfies the looser FSD requirements

in cases where some software changes it's license to something
unacceptable, but previous versions remain libre, the FSD entry
is modified with a warning about the last-known-libre version -
likewise, FSDG distros must freeze at that version or remove it
- an example of that happened a few weeks ago - if an FSD entry
is removed, or still pending approval, due to a confusion over
the license, that should suggest it's removal from FSDG distros

the information WRT nmap conflict though - the 'nmap' FSD entry
was not modified to indicate the confusion - rather, nmap (all
versions) was removed from the FSD entirely, because of the
confusion over the license, around the same time that donald
asked distros only to freeze it at the last-known-libre version
- the aggregate information is: nmap is FSDG-fit, but not
FSD-fit - but that is logically impossible, per the implication
that the FSD requirements are a proper sub-set of the FSDG
requirements- that is what i meant by conflicting information

the FSD and FSDG can and should always be in accordance about
that basic criteria: "is this program's license a free software
license?"; because the FSF maintains both the FSD and FSDG, and
the FSF defines what qualifies as a "free software license"

if ever the FSD and FSDG give conflicting information, that must
be an over-sight, a clerical error, or a lack of communication -
it can not be a disagreement - it wuold be the FSF disagreeing
with itself - disagreement among FSDG distros, about whether
that program is libre, should always indicate an an over-sight,
a clerical error, or whatever, to be easily corrected by the FSF


On Wed, 15 Mar 2023 00:39:13 -0300 Alexandre wrote:
> > that is as i assumed - but if a distributor chooses to drop the
> > extra permissions or restrictions per GPLv3 section 7, shouldnt
> > that entail to literally remove the extra terms from the license
> > file?
>
> That's not necessarily the case.

ok so in your opinion, distributors could advertise that very
un-gpl-like license as "the GPL"; because the option still
remains to remove the extra terms - they would not need to
remove the extra terms, nor to specify that it is a "custom"
license or a "modified GPL"? - that is really all im trying to
nail down in this case

that is reasonable, but there must be a limit - to contrast,
imagine that the extra terms added restrictions (per section 7,
say: non-commercial only) and also cancelled section 7 - surely,
that license could not be presented as "the GPL", because the
option would not exist to restore the original GPL terms


On Wed, 15 Mar 2023 00:39:13 -0300 Alexandre wrote:
> *nod*, yeah, it makes sense to wait for an official position.

my intention behind that statement is that i have asked, and
have been waiting for two years - the predicament is that FSDG
distros are distributing version of nmap, which the FSF
explicitly requested not to distribute, and which was removed
entirely from the FSD - while we wait, the FSDG, the FSD, and
FSDG distros are in a state of discordance

if the FSF is in uncertain about the license, then FSDG distros
should be equally doubtful, until the FSF is certain - if the
official position is concluded such that the license is not
acceptable, only then could distros and the FSDG work-group
begin to address the issue (eg: by engaging with the upstreams)
- before that happens, distros could do nothing but the wrong,
while distributing it - so it would be most sensible for distros
to avoid distributing it during that period of doubt


On Wed, 15 Mar 2023 00:39:13 -0300 Alexandre wrote:
> Until then, the recommendation to refrain from
> distributing the package identified as a potential problem seems as
> sound as it can get.

agreed - but some distros have not refrained - they decided on
their own, that the issue was resolved, and acted despite the
recommendation - i do not necessarily disagree with that
assessment; but i do disagree about acting despite the FSF's
recommendation, without first attempting to change the FSF's
recommendation, for the benefit of the other distros' users


On Wed, 15 Mar 2023 00:39:13 -0300 Alexandre wrote:
> I wouldn't put it that way.  It's our movement, our cause.  The FSF is
> an important part of the movement, but I don't see that it "owns" the
> cause.

i expressed that poorly - what i meant was that the FSF has
software freedom as it's mandate - we are only volunteers -
volunteers are not obligated to further the movement; but the
FSF is - the FSF is the authority on the GPL, the FSD, and the
FSDG; and _all_ of the critical maintenance tasks related to
those, can be done only by an authorized FSF representative

volunteers hands are currently tied by that bottle-neck on
multiple issues - volunteers who are helpless to be effective
for a long period of time, due to some administrative
bottle-neck beyond their control, are very likely to become
frustrated and stop helping

FWIW, i also did not intend that i would stop working on
parabola - i meant that i would stop participating in the FSDG
work-group, just as the majority of FSDG distros have already
decided to ignore it


On Wed, 15 Mar 2023 00:39:13 -0300 Alexandre wrote:
> Still, I can relate with your dissatisfaction, and share in the
> lamenting that this has been so.  I appreciate your sustained efforts
> and dedication to the cause, and thank you for them.  I also appreciate
> the FSF's, and thank it for them.
>
> Our movement has been through some particularly challenging times, and I
> hope we can keep on counting on your support, tolerance and patience
> with these difficulties a while longer.

spoken like a true politician :) - ok, ill bite - how long should
a reasonable person wait? - another 5 years? - that is already
how long the FSDG process has been stalled

that was a rhetorical question - myself, i dont need
encouragement; but the broader community does - i am still here,
and still trying to improve the FSDG process; although the
amount of patience and persistence that requires, is not
reasonable - most people are not so patient or tolerant of
administrative bottle-necks - they just jump ship

to thank people for such unreasonable dedication is great,
though those people obviously do not expect thanks - i lament
over the momentum and respect for the FSDG which has been lost,
because reasonable people have understandably lost faith in it's
efficacy - we can only hope for that to be restored someday,
somehow


On Wed, 15 Mar 2023 00:39:13 -0300 Alexandre wrote:
> Restating demands that still can't be met due to circumstances that are
> outside the control of the demanded party, or adding to the pressure
> about them, unfortunately neither fills the position nor qualifies other
> staff to issue the legal opinion that would back the demanded statement.

that would be a reasonable statement, except that the position
_was_ occupied during the first two years since the FSDG process
has been stalled - i started stating and re-stating the problems
which need attention, while the position was occupied

i was not even aware that the position was vacated, until about
a year after the fact; because the previous officer paid such
little attention to our concerns anyways - we did not even
notice that the office was empty - maybe that comes across as
cynical; but thats what happened

i dont think this is a backlog problem - i think it is matter of
priorities - i think that the FSD, the FSDG, and the RYF, should
have high priority in the FSF licensing office - i remember
donald explaining that the RYF is a priority and is very
time-consuming - i see the RYF and FSDG as going hand-in-hand,
with equal importance - the FSDG is not very time-consuming
though - volunteers do 99% of that work - that bottle-neck has
only a little pressure to release, and only on rare occasions -
it only needs to be elevated to the same importance as the RYF



reply via email to

[Prev in Thread] Current Thread [Next in Thread]