Re: Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Tobias Frost]

Hi Andreas, 

On Mon, Aug 30, 2021 at 08:25:29AM +0200, Andreas Tille wrote:
> Hi,
> 
> since this issue becomes complex I'd like to bring up it at debian-legal
> list for advise.
> 
> Kind regards
> 
>  Andreas.
>


(usual disclaimer: IANAL. This below is only are few cents and thought on the
matter. Warning, personal opinions incoming!)

I don't think we've got a legal/license problem here... For sure (and upstream
author seems to ACK this, it seems we'd be allowed to have change as we
see fit.

I think this a "social" type problem, possiblry the upstream author
not really understanding what "GNU" and the Free Software Movements stands for?
Or ignoring the 4 Freedoms for own benefit? I had this impression when I read
this from the FAQ [1]:

> If the goal had been to get more users, then the license would have
> been public domain.

The FAQ itself seems to be crafted to somehow "disguise" that the citing is
optional. As a non-native English speaker, after reading the FAQ, I would have
though that this citing is indeed an requirement, not a request. It seems to
use morailty obligations as a base argument.

[1] 
https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/citation-notice-faq.txt

(For documentation, upstream says in #915541#72 that it is thought to be 
optional)

Is the FSF aware that upstream had registered "GNU PARALLEL" as trademark, on
his name?  (Though, it is listed as "abandoned", whatever this means. I guess
it is not valid anymore.) Is upstream aware that "GNU" is a registered
trademark?

I think a pledge to cite is OK, but _requiring_ to run the programm with
certain command line options to so is in my books a click-wrap license, even if
the authors does claim otherwise, eg. in its FAQs: You need to do _some thing
explicitly_ that somehow makes you making a promise, maybe even a contract. So
it is natual, that someonoe is going to patch that out sooner or later -- if 
only
to avoid the annoyance  As said earlier, there is nothing in the license that
require us to keep the pledge, so upstream would be better off for their own
interest if the pledge is formulated in a way that noone actually want to go the
extra mail to remove the pledge.

Maybe carrying such a patch would NOT establish a fork (-- upstream has a
Rename (pledge / requirement) on forks in their FAQ; This could or could not
end up as effecitvly part of the license. If it is, sure, DFSG allows a
different name requirement, but it would certaintly be part of weight on the
overall judgment wether we should have the software in Debian at all.
However, source package name  is "parallel" "GNU parallel", so might we be
already ship it renamed... (Parallel alone would IMHO not be trademarkable, as
it is a common word and the parallel existed as tool already before GNU
parallel...) and removing GNU Parallel from the rest can be easily done, if
upstream prefers that.

In my experience its not good to do against the wish of an upstream author.
That does not mean that we should follow his request either.

My 2 cents: Possibly this GNU parallel should not be part of Debian, due to the
bitter taste this discussion leaves, but it has reverse dependcies, so not
really an option.

I dont think that shipping the software in non-free would service Debian and its
users as well: We'd still have to track down all reverse (build-) depdencies (if
and worst case put them to contrib, if patching is not possible.

So I guess I'd just patch and if upstream complains rename the project from
"GNU parallel" to just "parallel". Possibly somewhere is a fork already, didnt
check. Then switching to this fork would be an option as well.

Regarding the arguments upstream brings about the DFSG. Instead of rebuting them
individually  let me just quote some sentences of DSFG FAQ:

> "The process involves human judgement. The DFSG is an attempt to articulate 
> our
> criteria. But the DFSG is not a contract. This means that if you think you've
> found a loophole in the DFSG then you don't quite understand how this works."


> On Mon, Aug 30, 2021 at 08:08:26AM +0200, Ole Tange wrote:
> > Ian Turner  wrote:
> > > On 8/28/21 7:41 AM, Andreas Tille wrote:
> > 
> > If the revised wording (from version 20141022 to version 20210722)
> > does not change your opinion, I feel the only compromise that is
> > acceptable to all the active parties is to keep the citation notice
> > even if this means moving the software from main to non-free.

I dont think that is an acceptable "compromise to all the active parties", as
it seems to leave out the interests of our users. #884793.

IMHO a compromise could be to the citation "request" in the documentation,
like the example given in the DFSG FAQ. Remove the urge that people want
to patch something out and it won't.



- 
tobi

Re: Acceptability of a documentation license for Debian

[Francesco Poli]

On Sun, 29 Aug 2021 20:16:57 -0400 Jeffrey H. Johnson wrote:

> Greetings,
> 
> I'm contacting the list to inquire regarding the acceptability
> of the following proposed documentation license, as I'd like to
> ensure that it will become be an impediment to having
> documentation licensed under it added to Debian in the future.

Hello,
you seem to be drafting (possibly along with other people) a new
license that you propose for documentation.

Even before commenting the details of the license text, I would like to
express my own personal opinion on the operation itself.
My personal recommendation is: please, don't.

License proliferation is harmful, and adding another newly drafted
license to the already excessively long list of existing licenses
should be avoided, unless absolutely necessary.
Writing a good license text, avoiding all the subtle pitfalls that may
cause unexpected results, is a very hard task: even legal experts may
spend a very long time and yet come up with a flawed text.
The use of existing, well-known and well-vetted licenses is highly
recommended.

Moreover, you are proposing a license specifically designed to be
applied to documentation only.
This is a poor choice, because the boundaries of what is exactly
"documentation" are not so well-defined as one might think.
In my own personal opinion, a good license should applicable to any
kind of software (in the broad sense of the word, see my [essay] on the
topic, for more details).

[essay]: 


You are searching for a good simple and permissive license that can be
applied to documentation.

My recommendation is: if you are writing documentation for a specific
program or library, use the same license as the program or library
itself. This allows anyone to transfer material back and forth between
the program or library and the documentation without having to ask for
additional permissions (for instance: material from the documentation
may be used to enhance the online help of a program or the comments in
the source code of a library, and vice-versa).
In the case of DPS8M, I seem to understand that the majority of the
code is under the [ICU license], which looks perfectly OK for
documentation as well (and meets the DFSG).

[ICU license]: 

[zlib]: 

[...]
> Thank you,

Thanks to you for asking for advice!
I hope my reply may be helpful.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpEbZL3669IF.pgp
Description: PGP signature

Re: Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Felix Lechner]

Hi,

> On Mon, Aug 30, 2021 at 08:08:26AM +0200, Ole Tange wrote:
> >
> > If you want to remove the citation notice ...
> > nothing else gives you the right to change it.

Can we ship GNU Parallel with a small wrapper that removes the notice?
Being text-based, it would not modify the software at all. I am
thinking about something like:

$ echo 'NOTICE: Wanted output.' | perl -pe '{ s/^NOTICE:\s*(.*)/$1/ }'
Wanted output.

> Is the FSF aware that upstream had registered "GNU PARALLEL" as trademark, on
> his name?  (Though, it is listed as "abandoned", whatever this means. I guess
> it is not valid anymore.) Is upstream aware that "GNU" is a registered
> trademark?

A trademark does not have to be registered in order to be enforceable,
although it makes it easier. Many trademarks are not registered. The
USPTO application for "GNU Parallel" was filed on April 7, 2018 and
abandoned on February 4, 2019. I did not check Danish, EU or WIPO or
US state records.

I find it hard to believe the FSF would agree to the issuance. The
term "GNU" is their word mark (#f4125065) for goods and services in
the international categories 9 ("electronic apparatus and software")
and 16 ("documentation and manuals"). FSF may be able to exercise
additional pressure to prohibit "GNU Parallel" from using the word
"GNU".

Either way, the trademark threat in GNU Parallel's documentation is
explicit and refers to past legal cases: "This principle has even been
tested in court". [1] The author's aggressive stance, as evidenced by
a relatively recent trademark filing, should lead us to proceed with
extreme caution.

(I am one of Debian's trademark delegates, but have no trademark or
legal training. Please consult a competent person before relying on
anything in this message.)

Kind regards
Felix Lechner

[1] 
https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/citation-notice-faq.txt

Re: Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Andreas Tille]

On Mon, Aug 30, 2021 at 06:18:20AM -0700, Felix Lechner wrote:
> 
> Can we ship GNU Parallel with a small wrapper that removes the notice?
> Being text-based, it would not modify the software at all. I am
> thinking about something like:
> 
> $ echo 'NOTICE: Wanted output.' | perl -pe '{ s/^NOTICE:\s*(.*)/$1/ }'
> Wanted output.

I admit I also considered a wrapper but with a different functionality:
Simply check whether --citation was used before and if not do so.

I did not implemented this since from a user point of view the visible
effect is the same as the patch and the upstream author is probably
similarly (un)happy about it as the patch.

Kind regards

Andreas.

-- 
http://fam-tille.de

List of journal

[Bastien ROUCARIES]

Hi,

Could you do a review of https://github.com/JabRef/abbrv.jabref.org/ ?

I do not know the legal status of this kind of database

Bastien

Re: Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Ole Tange]

On Mon, Aug 30, 2021 at 3:38 PM Andreas Tille  wrote:
:
> I admit I also considered a wrapper but with a different functionality:
> Simply check whether --citation was used before and if not do so.

If you mean a wrapper similar to this, then that would be a compromise
I can live with:

if [ -t 2 -a ! -e "$HOME/.citation-run" ] ; then
  # Only run if stderr is a terminal (to avoid breaking scripts)
  parallel.real --citation
  touch "$HOME/.citation-run"
fi
parallel.real "$@"

By testing if stderr is redirected this should avoid breaking scripts
(e.g. cron jobs or similar).

To me it would feel similar to a dialog box, where you have to click
"Don't show this again" to continue the first time. This is not that
uncommon in graphical tools, so there is some precedence for this.

I find it less than optimal, but if we can find common ground on that,
it would be a compromise I can live with.


/Ole

Re: List of journal

[Walter Landry]

Bastien ROUCARIES writes:
> Could you do a review of https://github.com/JabRef/abbrv.jabref.org/ ?
>
> I do not know the legal status of this kind of database

According to

  https://github.com/JabRef/abbrv.jabref.org/blob/master/LICENSE.md

it is covered by CC0, which is fine for Debian.

Cheers,
Walter Landry

Re: Acceptability of a documentation license for Debian

[Jeffrey H. Johnson]

I thank everyone for the feedback,

Rather than address every individual point of the replies, or propose
updated text, it might be most helpful to explain the intent. I absolutely
will take into consideration and agree with comments and concerns
regarding license proliferation.

The documentation/work to be produced is additional "book-style" long-form
documentation, which will aim to document not only DPS8M but also provide
background information on the platform, the instruction set and
architecture, and the people involved (with the hardware and software,
both current and historical), so there is a need to alleviate and minimize
any concerns, founded or not, that potential contributors to the work may
have. While using the ICU license is an option (and it will in fact be
used for some of the documentation), for the 'book', it may require
additional buy-in or result in differing contributions to the final work.

1. Because of the 'personal' nature of some of the planned materials that
will be included, it's important for those potential contributors to be
able to voice their opinions and view of history but not have their
authorship nor these views and opinions later misattributed or
misrepresented, while also making clear that those views and opinions of
the authors are not official policies of the development and documentation
team.

2. The simulator itself will bundle man pages and some documentation as
well as provide online help within the simulator, which of course will be
licensed under the ICU license.

3. The project is not only a platform simulator, but a distribution/suite
of programs, which includes utilities and tools  -- Auditing the
distribution for license compatibility and compliance has certainly been a
chore and there is still some work to do.  For example, we've removed
and/or completely rewritten some questionable code (such as small amounts
of code that seem to have come from glibc, or licensed under non-
commercial terms, or without any clear lineage to all), clarified the
licenses of other code and contacted the original authors of that code
when necessary, and fully documented all licenses as we go along (the
https://gitlab.com/dps8m/dps8m/-/blob/master/LICENSE.md file) to ensure
that all contributors receive proper attribution. We've also ensured that
scripts and parts of the build system are properly licensed just in case
(this isn't BSD custom, which I am more familiar with).  We don't want the
license in the documentation to imply it is the license of the software,
which in many cases, it will not be.

4. In documenting the simulator and architecture, we will inevitably end
up using some Multics source code, which will require reproduction of the
Multics historical background and copyright notice -
https://opensource.org/licenses/Multics - the proposed documentation
license is intended to convey similar terms.

5. As state above, there is concern at the phrasing of "the Software" as
used in these licenses (such as zlib), when applied strictly to
documentation. We do not want misunderstandings or confusion that the
documentation is the simulator software, bundled utilities that the
documentation describes but are differently licensed, etc.  I do
understand there are subtleties as to exactly what is documentation and
what is not, and the licenses such as zlib further exacerbate this issue
by making an implied distinction between the documentation and the
software, for example:  "Permission is granted to anyone to use this
software ..." and later "an acknowledgment in the product documentation
would be appreciated".  This is especially confusing when the
documentation IS 'the software', and provides room for argument over the
resulting compiled documentation output (PDF, etc.).

6. Originally, the GFDL was discussed, but it is my understanding the the
GFDL is still controversial within Debian, and I would like to avoid the
situation where an optional dps8m-docs package would not be eligible for
inclusion, because having the simulator available in Debian is a personal
goal.  There are also other problems with the GFDL regarding DRM
distribution, etc.

7. Mostly a concern with GFDL-like license, but we want it to be clear
that this documentation is not restricted in distribution by medium,
including DRM'd mediums such as Amazon Kindle or Apple App Store markets.

8. Licensing the documentation under the same license as the software
would mean that some parts of the documentation (and different sections of
the book) would be need to be licensed under at least 1) the ICU License,
2) the zero-clause BSD license, 3) a two-clause BSD license, 4) a three-
clause BSD license, 5) a modified MIT license, and possibly parts 6)
released to the public domain.  I would normally agree that having the
documentation produced under the same license as the software is
preferred, but in this case, it seems that would be a nightmare.

It's not an 'official goal' of the project per se, and we are a wa

Re: Acceptability of a documentation license for Debian

[Tobias Frost]

On Mon, Aug 30, 2021 at 02:43:34PM -0400, Jeffrey H. Johnson wrote:

(IANAL, IANFTPM (I am not ftp master), etc.)

I hope you can really find a way to use a standard license. License 
profiliration
is really becoming harmful to FOSS.

ENOTIME for a complete reply to your mail, but two remarks:

(...) 

> 5. As state above, there is concern at the phrasing of "the Software" as
> used in these licenses (such as zlib), when applied strictly to
> documentation. We do not want misunderstandings or confusion that the
> documentation is the simulator software, bundled utilities that the
> documentation describes but are differently licensed, etc.  I do
> understand there are subtleties as to exactly what is documentation and
> what is not, and the licenses such as zlib further exacerbate this issue
> by making an implied distinction between the documentation and the
> software, for example:  "Permission is granted to anyone to use this
> software ..." and later "an acknowledgment in the product documentation
> would be appreciated".  This is especially confusing when the
> documentation IS 'the software', and provides room for argument over the
> resulting compiled documentation output (PDF, etc.).

Regarding Documentation and Software.
I've put some FreeCAD files under the GPL and had the same concern that some
work / 3d model might not be covered.  I've solved this for me by writing "For
the avoidance of doubt, "program" can be replaced with "work" in the license
grant above." below the GPL boilerplate in the README. Dont know if that
is legally watertight, but in conveys what I want to archieve.

> 6. Originally, the GFDL was discussed, but it is my understanding the the
> GFDL is still controversial within Debian, and I would like to avoid the
> situation where an optional dps8m-docs package would not be eligible for
> inclusion, because having the simulator available in Debian is a personal
> goal.  There are also other problems with the GFDL regarding DRM
> distribution, etc.

nope, GFDL and DFSG is settled.
https://wiki.debian.org/DFSGLicenses#Exception
As long as there are no invariant sections GFDL is acceptable.

Re: Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Tobias Frost]

On Mon, Aug 30, 2021 at 07:22:52PM +0200, Ole Tange wrote:
> On Mon, Aug 30, 2021 at 3:38 PM Andreas Tille  wrote:
> :
> > I admit I also considered a wrapper but with a different functionality:
> > Simply check whether --citation was used before and if not do so.
> 
> If you mean a wrapper similar to this, then that would be a compromise
> I can live with:
> 
> if [ -t 2 -a ! -e "$HOME/.citation-run" ] ; then
>   # Only run if stderr is a terminal (to avoid breaking scripts)
>   parallel.real --citation
>   touch "$HOME/.citation-run"
> fi
> parallel.real "$@"

Thats fragil.
There is no guarantee that a (system) user has $HOME that it is writable.




(Regardin what to do in Debian, maybe its time to resurrect #597050?)

-- 
tobi

Re: Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Tobias Frost]

On Mon, Aug 30, 2021 at 07:22:52PM +0200, Ole Tange wrote:
> To me it would feel similar to a dialog box, where you have to click
> "Don't show this again" to continue the first time. This is not that
> uncommon in graphical tools, so there is some precedence for this.

as explained earlier: click-wraps are no-no's.

(And it is a difference if it is a "Tip of the Day" dialog on a 
supposed-to-be-used-with the GUI
or a license/citation-nagger which is usually run in a script.
If you mean those. At least the former provides some advantage to the user, the
latter not, just as an starter.)
 
> I find it less than optimal, but if we can find common ground on that,
> it would be a compromise I can live with.

Hows about only print a decently worded message asking nicely to cite, without 
the
nagging to stdout if the user passes --help?
 
> 
> /Ole
>