Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install COPYING.txt #21571

Open
mkoeppe opened this issue Sep 22, 2016 · 36 comments
Open

Install COPYING.txt #21571

mkoeppe opened this issue Sep 22, 2016 · 36 comments

Comments

@mkoeppe
Copy link
Member

mkoeppe commented Sep 22, 2016

Use the installed location for COPYING.txt from sage.misc.copying.

Use src/doc/bootstrap to install a copy in src/doc somewhere as preparation for installation.

Perhaps autogenerate COPYING.txt from portions in build/pkgs/

Depends on #30912

CC: @williamstein @vbraun @jdemeyer @dimpase @tobihan @kiwifb @infinity0 @orlitzky

Component: build

Keywords: sd111

Issue created by migration from https://trac.sagemath.org/ticket/21571

@mkoeppe mkoeppe added this to the sage-7.4 milestone Sep 22, 2016
@embray
Copy link
Contributor

embray commented Sep 29, 2016

comment:1

I was about to make this ticket as well...

@mkoeppe
Copy link
Member Author

mkoeppe commented Sep 29, 2016

comment:2

Please feel free to work on it, or any other of the tickets that I have created.
If I didn't put my name on "Authors", I haven't done any work on it yet; so there's no danger of duplicating work.

@embray
Copy link
Contributor

embray commented Sep 30, 2016

comment:3

I think really, to get this right more work needs to be done on cleaning up the setup.py.

@mkoeppe
Copy link
Member Author

mkoeppe commented Oct 15, 2016

comment:4

Replying to @embray:

I think really, to get this right more work needs to be done on cleaning up the setup.py.

Is it feasible to do this one on top of #21604 and #21600, or is more cleaning needed first?

@embray
Copy link
Contributor

embray commented Oct 17, 2016

comment:5

I mean, part of the problem is "COPYING.txt" does not even exist in the root of the Python source code (that is, at or below setup.py). When we make a source distribution of sagelib it's going to have to have all the files it needs in it. So for starters we're going to have to copy COPYING.txt into src/

@mkoeppe
Copy link
Member Author

mkoeppe commented Oct 18, 2016

comment:6

Instead of copying, perhaps we can move it to src/
and replace it by a very short notice in COPYING.txt, pointing the user to src/COPYING.txt for more detail.
This would avoid duplication.

@mkoeppe
Copy link
Member Author

mkoeppe commented Oct 19, 2016

@mkoeppe
Copy link
Member Author

mkoeppe commented Oct 19, 2016

comment:8

Cc'ing a few people to see if this change to the layout of the license file(s) is acceptable.


New commits:

91f7b9aMove COPYING.txt to src/COPYING.txt, leaving behind a short notice

@mkoeppe
Copy link
Member Author

mkoeppe commented Oct 19, 2016

Commit: 91f7b9a

@mkoeppe mkoeppe modified the milestones: sage-7.4, sage-7.5 Oct 19, 2016
@embray
Copy link
Contributor

embray commented Nov 7, 2016

comment:9

I have a slight preference for just copying it. My mind is still that sagelib and all stuff related to the distribution should eventually be split into separate repositories. But that's of course an uphill battle so I'm fine with any interim solution.

@embray
Copy link
Contributor

embray commented Nov 7, 2016

comment:10

Actually, now that I take a closer look the license file for sagelib should really be entirely different. Almost none of the copyright notices for all the differenge sage packages apply to sagelib itself. Instead src/COPYING.txt could probably be little more than another copy of the applicable GPL.

@mkoeppe
Copy link
Member Author

mkoeppe commented Nov 10, 2016

comment:11

But we need a comprehensive license file to display to the user. It should display all relevant licenses of the packages that Sage uses, as it does now.

@embray
Copy link
Contributor

embray commented Nov 10, 2016

comment:12

That's....not true. It only needs to include licences for sources that are distributed with it. It does not need to be distributed with licences for all packages it might happen to link to.

@embray
Copy link
Contributor

embray commented Nov 10, 2016

comment:13

Sage-the-distribution provides its own distribution for all those packages so it makes sense there. But the "COPYING.txt" for sagelib itself only needs the licence for sagelib.

@jdemeyer
Copy link

comment:14

I agree with Erik. The licenses of Sage-the-distribution and Sage-the-library should not be confused. Whatever goes into src should be about Sage-the-library only.

@mkoeppe
Copy link
Member Author

mkoeppe commented Nov 10, 2016

comment:15

Are you saying that

sage: copying()

should only print the license of sagelib?

@mkoeppe
Copy link
Member Author

mkoeppe commented Dec 30, 2016

comment:16

Cc'ing people who work on distro packaging to get more input on what copying() should print.

@embray
Copy link
Contributor

embray commented Dec 30, 2016

comment:17

I don't know what copying() should print, but the license file that needs to be included in the source tarball for just sagelib should just be the license for sagelib.

Perhaps, if the full sage distribution license file is installed to a standard place in the sage distribution then copying() could also try to read and display that. But if sage is installed, say, by a Linux distro not using the full sage distribution then it's not as relevant.

@infinity0
Copy link
Mannequin

infinity0 mannequin commented Jan 6, 2017

comment:18

I patched the Debian package to display the Debian copyright file for copying():

https://anonscm.debian.org/cgit/debian-science/packages/sagemath.git/tree/debian/copyright

which is basically everything not in the spkgs (which we're using Debian packages in the place of). So, sagelib but also build scripts and other misc things left in the source tree.

@jdemeyer

This comment has been minimized.

@jdemeyer jdemeyer changed the title Install COPYING.txt in SAGE_LOCAL and use it from misc/copying.py Install COPYING.txt and VERSION.txt Apr 9, 2018
@embray
Copy link
Contributor

embray commented Apr 11, 2018

comment:20

Per the title, this should apply a similar fix for VERSION.txt as discussed in #25056 comment:39

@kiwifb
Copy link
Member

kiwifb commented Apr 11, 2018

comment:21

The branch needs to be rebased. And we have to be clear about what we are doing here. #25056 means that in sage-8.2 the sage start up script will refer to SAGE_ROOT/VERSION.txt I fixed that in sage-on-gentoo but it will bite debian and the other.

We should have a consensus on where those files live and apply it.

@embray
Copy link
Contributor

embray commented Apr 12, 2018

comment:22

Upon re-reading this issue I don't think we should conflate handling of VERSION.txt into it. There was still some question in this issue as to handle the actual license text--IMO there needs to be separate license files covering Sage-the-distribution (and hence licenses of all the bundled software and the license for the build tools) and Sage-the-library.

The VERSION.txt issue is simply matter of having a reasonable standard place to install this file. I will open a new ticket for that with a proposed solution and set it as a blocker for 8.2.

@slel
Copy link
Member

slel commented Apr 26, 2018

comment:23

Replying to @embray:

The VERSION.txt issue is simply matter of having a reasonable standard
place to install this file. I will open a new ticket for that with a
proposed solution and set it as a blocker for 8.2.

For reference the new ticket Erik opened for this is #25150.

@jhpalmieri
Copy link
Member

comment:24

Should each package have a file with its license, and then COPYING.txt would be autogenerated from those? Either from all standard packages, or from all packages, or from all packages which will be installed according to ./configure.

@kiwifb
Copy link
Member

kiwifb commented Jul 18, 2020

comment:25

Replying to @jhpalmieri:

Should each package have a file with its license, and then COPYING.txt would be autogenerated from those? Either from all standard packages, or from all packages, or from all packages which will be installed according to ./configure.

I don't think that is necessary. Each package should install its own license if required. The question is specifically about sagelib's COPYING.txt file which is currently under SAGE_ROOT and sage/misc/copying.py is looking for it exactly there which is inconvenient for distros.

I think doing something like #27171 would be appropriate.

@mkoeppe
Copy link
Member Author

mkoeppe commented Dec 10, 2020

Changed keywords from none to sd111

@mkoeppe mkoeppe modified the milestones: sage-7.5, sage-9.3 Dec 10, 2020
@mkoeppe

This comment has been minimized.

@mkoeppe
Copy link
Member Author

mkoeppe commented Dec 11, 2020

@mkoeppe
Copy link
Member Author

mkoeppe commented Dec 11, 2020

Changed commit from 91f7b9a to none

@orlitzky
Copy link
Contributor

comment:29

Some thought should go into this one. First... we don't install COPYING.txt in Gentoo because it's redundant. The type of license is part of the package, and it's up to the maintainer to figure out what license type should go in the package. (This allows users to restrict what licenses are allowed on his machine.)

One consequence of that is that the Gentoo developer has to dig through the source of the package, and list every license that he sees. If the main project is GPL-2 but if one file says BSD at the top, we include both. This is not legally accurate, though; it's done only because we don't want maintainers to have to worry about legal issues! So if you decide to include every COPYING.txt from every spkg, be aware that you're doing essentially the same thing.

This overlooks two subtle issues. The first is that. when installed, all of the licenses used had damned well better be compatible. If not, you have a legal problem.

Then, if they are compatible, they are often subsumed into the most restrictive license in a way that makes e.g. "GPL-3" the only effective license. If you release code as public domain, I can take it and make it GPL-3. So while I may say that my package has both "public domain" and "GPL-3" code, it would make more sense to say that the license is GPL-3. When linked, it will be the GPL-3 that is in effect. Adding a COPYING.txt that mentions the public domain would be misleading at best.

So, to summarize, copyright is stupid, and we should be really sure that we know what problem we're trying to solve here before we solve it.

@kiwifb
Copy link
Member

kiwifb commented Dec 11, 2020

comment:30

Technical aspect first: currently sage has a function called license that essentially read COPYING.txt located in SAGE_ROOT. And it is doctested.

As you can imagine, it thrills me.

The second issue is that the current file which is a meta distribution COPYING.txt is supposed to aggregate the license of all the packages shipped. As a set file, unless it lists all possible licenses ever, it is obsolete by design. It ought to be generated.

Legal point, yes copyright can be stupid. But license compatibility really kicks in when you distribute binaries. So long as you distribute only source code and you build it yourself, you don't have to worry about it. Of course who does build by themselves these days :)

As sage-on-gentoo I seek a solution to the first aspect. Runtime shouldn't depend on SAGE_ROOT. sagemath needs to fix the second aspect as well for themselves.

@orlitzky
Copy link
Contributor

comment:31

The technical problem can be solved by deleting sage.misc.copying =P

The legal issues can be solved by... somebody else.

@mkoeppe
Copy link
Member Author

mkoeppe commented Dec 11, 2020

comment:32

I'll add a simple license file for sagelib only to src/ in #30912

@mkoeppe
Copy link
Member Author

mkoeppe commented Dec 12, 2020

Dependencies: #30912

@mkoeppe
Copy link
Member Author

mkoeppe commented Mar 24, 2021

comment:34

Sage development has entered the release candidate phase for 9.3. Setting a new milestone for this ticket based on a cursory review of ticket status, priority, and last modification date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants