About the license file

[Qian Yun]

There are 2 (minor) issues about the license file:

1. GitHub doesn't recognize it because it's located at
"license/LICENSE.AXIOM".

2. I plan to add the license file (and a readme) to the
Windows and macOS binaries, the name "LICENSE.AXIOM" might
be misleading.

So I propose to move "license/LICENSE.AXIOM" to "LICENSE".

Just tested on my branch, a simple rename will cause GitHub
to recognize the license file.

Furthermore, shall we add something like this to it?

Copyright (c) 2002-2007, The Axiom Team
Copyright (c) 2007-2023, The FriCAS Team

- Qian

[Tim Daly]

Seems reasonable to me. Licensing and copyright issues are fine.

It is only the trademark issue that matters.

[Waldek Hebisch]

I feel that we should keep LICENSE.AXIOM as is, at least for
some time. It records original copyright of the sources and
there are external references. To resolve the issue
I think we should copy content of this file to "LICENSE"
and add the extra copyright statements as above.

If there is no voices against I will do in about a week.

--
Waldek Hebisch

[Qian Yun]

Now that "LICENSE" is committed, there's a minor problem:

On case-insensitive filesystems, "LICENSE" file is colliding
with "license/" directory.

I have confirmed that unpacking fricas-master.zip (from GitHub)
on Windows causes problem: "LICENSE" is created while "LICENSE.AXIOM"
is not. (Similar problem might happen for git checkout.)

So considering rename the "license/" directory? (e.g. "licence")

- Qian

[Waldek Hebisch]

On Thu, Nov 30, 2023 at 06:01:41PM +0800, Qian Yun wrote:
> Now that "LICENSE" is committed, there's a minor problem:
>
> On case-insensitive filesystems, "LICENSE" file is colliding
> with "license/" directory.
>
> I have confirmed that unpacking fricas-master.zip (from GitHub)
> on Windows causes problem: "LICENSE" is created while "LICENSE.AXIOM"
> is not. (Similar problem might happen for git checkout.)
>
> So considering rename the "license/" directory? (e.g. "licence")

Well, I am not sure if that is really a problem. One reason to
keep license/LICENSE.AXIOM is because people where told that
orignal NAG license is there. Renaming would defeat this.
OTOH Windows and Mac folks can fetch LICENSE.AXIOM from Github,
I think that is enough. So as long as download do not produce
errors I think that we can live with this.

--
Waldek Hebisch

[Ralf Hemmecke]

Waldek,

now that you suggest that LICENSE.AXIOM can be downloaded from github,
I think we can savely remove "license/" completely and write a note to
the end of the LICENSE file that the orginal NAG license file is in the
very first commit of the git repository.

It would be safe to check this out even on case insensitive file systems.

Ralf

[Dima Pasechnik]

Windows can be told to be case-sensitive in a given folder:
https://www.howtogeek.com/354220/how-to-enable-case-sensitive-folders-on-windows-10/

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/0e045f4b-09c9-4e00-9cd0-db82c57ad470%40hemmecke.org.

[Tim Daly]

Ralf, actually the license has to accompany every download.

I spent a lot of time with NAG about requiring license and

license text (in each file). Their lawyers required it. So I don't

think it is sufficient to refer to github. The license (whatever

its name) has to be included in the download.

Tim

[Ralf Hemmecke]

Hi Tim,

thank you for chiming in.

On 11/30/23 19:49, Tim Daly wrote:
> Ralf, actually the license has to accompany every download.
> I spent a lot of time with NAG about requiring license and
> license text (in each file). Their lawyers required it. So I don't
> think it is sufficient to refer to github. The license (whatever
> its name) has to be included in the download.

%>diff LICENSE license/LICENSE.AXIOM
1,3d0

< Copyright (c) 2007-2023, The FriCAS Team
< Copyright (c) 2002-2007, The Axiom Team
<

So, in fact, the new LICENSE file IS the NAG license file, it just
reflects that newer development has other copyright attributions.

I do not think that basically moving license/LICENSE.AXIOM to LICENSE
and adding the above 3 lines at the top can in any way violate the
requirement that you got from NAG. I am not a lawyer, but I just think
it is legally safe to remove license/LICENSE.AIXIOM and only retain LICENSE.

What to you think?

Ralf

[Qian Yun]

If so, let's rename "LICENSE" to "LICENCE" then.

Current status will definitely causes trouble/confusion to
(windows/mac) users in the future.

- Qian

[Qian Yun]

On 12/1/23 07:44, Qian Yun wrote:
> If so, let's rename "LICENSE" to "LICENCE" then.

Or rename to "LICENSE.txt".

- Qian

[Tim Daly]

The name and location of the file doesn't matter.

I chose license.axiom because I included a license file

for every piece of software Axiom used. The convention was

license.othersoftware for each othersoftware. I gathered all

of the licenses into a single directory so it was clear where to look.

The only NAG requirements were that the license had to be included

with each copy and the license text in original files had to

include the license information. NAG did not want to be liable

for someone using the software.

 

Feel free to move the license filename anywhere as long as it

is included in every copy.

As for the filename case-sensitivity it is simple to change all of the

filenames everywhere to be lower case. It is not a difficult patch.

Axiom did that years ago.

Tim

[Waldek Hebisch]

On Fri, Dec 01, 2023 at 07:59:09AM +0800, Qian Yun wrote:
>
>
> On 12/1/23 07:44, Qian Yun wrote:
> > If so, let's rename "LICENSE" to "LICENCE" then.
>
> Or rename to "LICENSE.txt".

If Github recognizes "LICENSE.txt", then we can do this.

--
Waldek Hebisch

[Richard Westhaver]

friendly suggestion: name one COPYING?

> On Nov 30, 2023, at 20:01, Waldek Hebisch <de...@fricas.org> wrote:

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZWkwTAUs9klSsNdL%40fricas.org.

[Grégory Vanuxem]

hello,

Personally I do not see the point of having two license files. The
actual LICENSE file from GitHub is still BSD-3-Clause and conforms to
what NAG asked from my point of view. You can check LICENSE file here
for example: https://tools.spdx.org/app/check_license/.

Regards,

- Greg

Le ven. 1 déc. 2023 à 02:32, Richard Westhaver
<richard....@gmail.com> a écrit :

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/22F97076-A385-4734-AA8D-70F6573E823A%40gmail.com.

[Qian Yun]

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license

==== QUOTE
Most people place their license text in a file named LICENSE.txt
(or LICENSE.md or LICENSE.rst) in the root of the repository;
==== END QUOTE

So please do the rename, this way the old license file is
not touched -- everybody is happy.

- Qian

[Ralf Hemmecke]

On 12/1/23 11:51, Qian Yun wrote:
> https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license
>
> ==== QUOTE
> Most people place their license text in a file named LICENSE.txt
> (or LICENSE.md or LICENSE.rst) in the root of the repository;
> ==== END QUOTE
>
> So please do the rename, this way the old license file is
> not touched -- everybody is happy.

Well, maybe not quite everybody.

I rather propose to commit the attached patch.

Ralf

[Tim Daly]

Please note that the NAG copyright license is not the only license

that applies. There are quite a few others that need to be cited

(per U.S. copyright law anyway). There are 12 in the license directory.

https://github.com/daly/axiom/tree/master/license

These additional licenses should probably be cited if they were ever part

of the github history since the code is available in the git download distribution.

The NAG version I originally received was implemented in CCL.

I rewrote it in AKCL but the CCL license still applies to the original sources.

AKCL is now GCL so that new license likely applies. Check with Camm.

Some of them probably don't apply, such as the LAPACK license.

I rewrote LAPACK into Common Lisp and included the newly rewritten

code into the source tree. Despite the fact that no LAPACK code is included

it is still ethically correct to include that license. I think this change is

post-fork so it may not apply.

Tim

[Waldek Hebisch]

On Fri, Dec 01, 2023 at 07:03:23AM -0800, Tim Daly wrote:
> Please note that the NAG copyright license is not the only license
> that applies. There are quite a few others that need to be cited
> (per U.S. copyright law anyway). There are 12 in the license directory.
> https://github.com/daly/axiom/tree/master/license

Well, extra things that were in Axiom are removed from FriCAS
and we did not add new ones.

> These additional licenses should probably be cited if they were ever part
> of the github history since the code is available in the git download
> distribution.

Well, if somebody is doing 'git clone' they will also get removed
licence as part of history. If they check out old version they
will get relevant licence as part of checkout. INAL, but in
may opinion that is fair: "location" of licence file is no more
obsure than "location" of files to which it applies.

Concerning GCL and CLL: they were never part of FriCAS repository
(there was provision to add GCL to FriCAS distribution tarball,
but this was done outside of repository).

--
Waldek Hebisch

[Tim Daly]

I can't argue with your choices. They all seem perfectly reasonable to me.

Without legal advice I'd make the same choices.

I'm not a lawyer either. I usually ask my lawyer friend for advice

when I play with copyright or trademarks. Of course none of his

advice would apply outside the U.S. and since I'm not actually his

client I used to get either comments or pointers to textbooks on

the particular laws like trademarks (which that law required me to

"actively defend". Sigh.)

I occasionally tell him how illogical a particular law seems.

He just grins and ignores me. For example I asked him if it was

ok to remove the copyright notices in many of the input files

since the whole project already had a license file. He said to

consult with NAG. NAG said they had to remain.

I was very careful to include the license of any copyrighted foreign

code that may have been used at some time and might be buried in the

git clone. The copyrighted code would still be used if I were to

"git reset" to an historical version. (Yes, I know the license would

also appear but ...)

Distributing code (aka "a github clone") that contains copyrighted

code without every top-level license file seems reasonable but I

suspect that a non-technical jury wouldn't understand the subtle

distinction that "we no longer use that code" but still "distribute it".

My weak understanding is that copyright covers "distribution"

(aka "copy"), not use.

I have absolutely no idea what German law may require but if

it is anything like U.S. law, "reasonable" is not a valid defense.

Also, don't take legal advice from a programmer / mathematician (me).

Your University likely has a lawyer on staff.

Tim

[Waldek Hebisch]

I did the rename to LICENSE.txt. I think that updating references
in documentation is separate thing.

--
Waldek Hebisch

[Qian Yun]

I just realized that there is also this file: "src/etc/copyright".

What to do with it?

Note that this file is printed by ")copyright" command. So if
we decide to remove it, we should also adjust Makefile to install
LICENSE.txt to this location.

- Qian

[Ralf Hemmecke]

On 12/8/23 14:39, Qian Yun wrote:
> I just realized that there is also this file: "src/etc/copyright".

Pffff...

As always, IANAL. Additionally I can only guess what "copyright"
actually means. German law distiguishes between "Urheberrecht" and
"Nutzungsrecht". The Urheberrecht basically says something about the
creator of some work, the Nutzungsrecht says something about what can be
done with the work. That looks like a relatively clear distinction.
So basically all contributors to FriCAS can count as "Urheber" (creator)
of the work (FriCAS) and by German law one cannot give the fact that
he/she is the "Urheber" (in other words no German can put something into
"public domain"). As the creator of some work one has the exclusive
"Nutzungsrecht" (right to use the work). By a license one can allow
others certain rights to use, distribute, copy (or whatever) the work.

As far as I understand the american copyright is somewhat incompatible
with the above view. What one usually sees is a copyright note and at
the same time some text (list the BSD clauses) that say something about
what rights some (different from the original creators) person gets for
the "work". And that is called "LICENSE". Sigh!

I think the way we do it now with having a LICENSE file at the root of
the repo and src/etc/copyright is OK for me, but I can also imagine that
we just have a COPYRIGHT file at the root that is somehow like
src/etc/copyright (i.e. with portions copyright messages and the
respective license that the original copyright holders distributed with
the software). (All other license and copyright files should be removed,
because they get included into COPYRIGHT.) However, I would like that
the years are specified clearly. For example, the last line in
src/etc/copyright just says

Portions Copyright (c) Renaud Rioboo and the University Paris 6.

but give no starting and end year and no license part.

Ralf

[Tim Daly]

I am not a lawyer either but as far as I understand it copyright law

varies from country to country and is covered by treaty. All of that

is "way above my pay grade".

Despite having authored a reasonable bit of the code I claim no

copyright. In the U.S. I believe authored works are "born copyrighted".

I tried to be very careful about including any and all copyright text

for any piece of software ever used. Most of the law is intended to

allow people to sue. I don't want to play that game. Axiom trademark

protection requirements are painful enough and make me look like

"the bad guy" because I'm required to take action. Sigh.

Lawyers have spent lifetimes arguing over a single copyright like

GNU. I'm pretty sure I don't understand any of it.

Ralf writes:

"I would like that the years are specified clearly. For example, the

last line in src/etc/copyright just says

Portions Copyright (c) Renaud Rioboo and the University Paris 6.

but give no starting and end year and no license part."

Perhaps Renaud used some resources from his University

such as a University computer. If so then the University Paris 6

probably requires their copyright to be stated. Check with your

University legal department if you use their servers to host or

develop code at the University. Using their resources makes

them liable.

In a copyright dispute the goal is to get money so the University

is likely to be a party to a suit. When I worked at City College of

New York I explicitly included language in my job description

saying that the University had no claim to Axiom. I developed

on my own equipment and time. I hosted axiom-developer.org

on a server under my desk at home. I kept the same setup

when I worked at CMU.

I have no idea what French copyright law allows or requires.

In the U.S. I believe there is no requirement for year notation.

Also copyright in the U.S. extends from creation until

70 years beyond the death of the author.

It seems to me the safest course of action is to treat any

legal text anywhere as "binary code" and not try to interpret it,

delete it, modify it, or bury it.  I added the )copyright command.

Just to see how bad things can get:

https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes

Tim

[Tim Daly]

This link raises the issue of developer liability, especially in the E.U.

https://blog.hansenpartnership.com/solving-the-looming-developer-liability-problem/

If the software provides a method of attacking some business

the developers might be liable for damages.

One route, for example, might be to exploit the X11 or other socket-based

code to allow network attacks. The defensive measure would be to have a

cryptographic handshake between the interpreter and the X11 code. There

are many other exploit paths available.

This is only one of the rising legal problems. Another one is that the E.U.

is debating the question of whether software requires a "bill of materials"

which tracks what software was / is used as part of the delivery.

Tim

[Dima Pasechnik]

On Tue, Dec 12, 2023 at 1:58 PM Tim Daly <axio...@gmail.com> wrote:
>
> This link raises the issue of developer liability, especially in the E.U.
> https://blog.hansenpartnership.com/solving-the-looming-developer-liability-problem/

It's about a UK court case. UK has left EU a while ago :-)

And the court case is by someone with very deep pockets suing people
they allege have control over Bitcoin wallets or something.

IMHO UK courts are willing to take any silly business case, you'd just
have to pay, a lot...

>
> If the software provides a method of attacking some business
> the developers might be liable for damages.

it's like a robbed bank suing a gun manufacturer, demanding it
provided a feature disabling its guns
in the bank's buildings...

>
> One route, for example, might be to exploit the X11 or other socket-based
> code to allow network attacks. The defensive measure would be to have a
> cryptographic handshake between the interpreter and the X11 code. There
> are many other exploit paths available.
>
> This is only one of the rising legal problems. Another one is that the E.U.
> is debating the question of whether software requires a "bill of materials"
> which tracks what software was / is used as part of the delivery.

Once the legal system is broken, you are never safe, full stop.

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/958b0d0b-a21f-4a68-8fc7-6e8c7dfbaa7an%40googlegroups.com.

[Tim Daly]

PDF: Law For Computer Scientists And Other Folk

https://academic.oup.com/book/33735

[Waldek Hebisch]

On Fri, Dec 08, 2023 at 09:39:58PM +0800, Qian Yun wrote:
> I just realized that there is also this file: "src/etc/copyright".
>
> What to do with it?

I think it is best to remove it.

> Note that this file is printed by ")copyright" command. So if
> we decide to remove it, we should also adjust Makefile to install
> LICENSE.txt to this location.

The attached patch is doing this.

--
Waldek Hebisch

[Qian Yun]

LGTM.

P.S. to Ralf:

About the copyright file mentions Rioboo:

From an email by him to axiom-dev in 2014-Sep-10:

==== Quote
You can put any kind of free license on my code.

When I was at UPMC there were concerns about software licenses in
particular for the real closure package which was inside NAG's Axiom.
Things have much evolved now and we may distribute software with free
license.
==== END Quote

So we can remove "is the property of university Paris 6." in reclos.spad
to avoid confusion.

- Qian

[Tim Daly]

Debian posting about free and open software and the E.U.Cyber Resilience Act

https://bits.debian.org/2023/12/debian-statement-cyber-resillience-act.md.html

The European Union is currently preparing a regulation "on horizontal cybersecurity

requirements for products with digital elements" known as the Cyber Resilience Act (CRA).

It is currently in the final "trilogue" phase of the legislative process. The act includes a set

of essential cybersecurity and vulnerability handling requirements for manufacturers. It

will require products to be accompanied by information and instructions to the user.

Manufacturers will need to perform risk assessments and produce technical

documentation and, for critical components, have third-party audits conducted. Discovered

security issues will have to be reported to European authorities within 25 hours (1).

The CRA will be followed up by the Product Liability Directive (PLD) which will introduce

compulsory liability for software.

While a lot of these regulations seem reasonable, the Debian project believes that there

are grave problems for Free Software projects attached to them.

[Tim Daly]

Further analysis of the forthcoming E.U. Cyber Resilience Act:

https://berthub.eu/articles/posts/eu-cra-what-does-it-mean-for-open-source/

[Tim Daly]

EU's Cyber Resilience Act Passes with Wins for Open Source

https://pyfound.blogspot.com/2024/01/CRA-update.html