symbolic icon indicating copy to clipboard operation
symbolic copied to clipboard

[maint] possibility of shifting code to upstream Sympy

Open cbm755 opened this issue 8 years ago • 5 comments

Hi @maprieto, @latot, @genuinelucifer, @mtmiller, @carandraug, and any other contributors or potential contributors,

I've been thinking about having the option (now or in the future) of moving some code upstream to the Sympy project.

Facts:

  1. Symbolic pkg is licensed GPL-v3
  2. Sympy is BSD licensed ("new bsd, 3-clause" I think).
  3. Symbolic pkg depends strongly on Sympy.

Ideally Symbolic should be a thin layer over Sympy. But sometimes that's not so, for example, there is substantial code in @sym/fourier.m. I think there could arise compelling reasons to move code upstream (for example, it might be better maintained, subject to wider usage, etc).


I'm considering drafting some sort of "contributor agreement" that would:

  1. Allow [1] the de facto maintainers (at that time),
  2. to relicense code to BSD for the purposes of contributing it to Sympy,
  3. or its current dominant fork (essentially whatever project is the main dependency of Symbolic at that time),

I'd like to know that if a such a thing were carefully prepared [2], what are your thoughts?

  1. Would you be less likely to contribute to Symbolic? (e.g., b/c its weakening GPL protection or you have a strong dislike for "CLAs").
  2. Do you agree the benefits of sharing code upstream offset the risks [3] of such a move?
  3. Or maybe you think the BSD license would've been fine for Symbolic originally (given its dependency on Sympy).
  4. Or maybe you're not concerned about licensing and have no strong opinions (that's fine, I'm not being judgmental here!)
  5. Something else?

Thanks for reading and I welcome opinions.


[1] Even without such a thing, we can relicense code from an specific .m file with the permissions of those who are listed as copyright holders in that .m file. The point here is the deferring of that decision to the de facto maintainers.

[2] I have discussed informally with Bradley Kuhn who didn't seem to think it was a terrible idea, although he certainly cautioned about limiting the wording to the specific case. (If we decide to go further with this, I could ask him to read a draft).

[3] Even without Sympy, our documentation and test sets are extensive. A situation one might worry about is someone replacing the Sympy backend with a proprietary CAS and shipping the non-Free result. Not possible under GPL-v3 but certainly possible if all of Symbolic was BSD licensed.

cbm755 avatar Feb 03 '17 18:02 cbm755

Would you be less likely to contribute to Symbolic

I don't see any particular reason for that. I have really no favorites as far as licensing goes if it still gives due credit to whoever submitted that piece of code.
I like the idea of moving more code upstream as it would be subject to more usage. :)

genuinelucifer avatar Feb 03 '17 19:02 genuinelucifer

My contributions have mostly been on the side of maintainer stuff (configure.ac and Makefile) so seems like this wouldn't affect me.

I can see where you are coming from with the CLA and I'd be ok with it because I have meet you and been following the project. If I was new, the idea of a CLA would make me think twice, even more than if the whole project was BSD. I guess this is completely irrational, but a CLA requires realizing that a change to a weaker licence in the future is possible while if the whole project was BSD, that was just the status quo and there would be nothing to think about. This would have been very much stupid on my part, obviously a CLA under those conditions would be a better protection. I guess a well written CLA may make this a non-issue.

carandraug avatar Feb 07 '17 13:02 carandraug

After the experience of coding in @sym/fourier.m and @sym/dsolve.m, I think that it'd be a pretty good idea to try to keep Symbolic as thin as possible moving code upstream in Sympy. With this purpose, I agree with @carandraug that a well written CLA would be a must.

maprieto avatar Feb 09 '17 09:02 maprieto

I agree with the rest. The idea of a CLA raises questions for me in general, but if the wording and the intent are well understood to apply to releasing code to the upstream project, it sounds acceptable.

OTOH you have about a dozen contributors listed. If it's easy enough to git blame and chase a few people for permission to relicense particular blocks of code, I have seen that done on smallish projects as well (gnulib, gnutls, and openconnect are the three that come to mind that have occasional "may we copy this chunk of code under a different license" topics).

mtmiller avatar Feb 09 '17 16:02 mtmiller

An alternative is reducing the chances of the CLA ever being necessary. We realize now that the symbolic should be a wrapper as thin as possible so any big changes should be redirected to sympy from the start.

carandraug avatar Feb 12 '17 00:02 carandraug