Clarify license agreement

[DougRzz]

Hi,

Following this update from Handsontable to its license agreement, please could you confirm the MIT license status of ipysheet still stands. Thanks.

https://handsontable.com/blog/articles/2019/3/handsontable-drops-open-source-for-a-non-commercial-license

[martinRenou]

Thanks very much for sharing the news! We'll discuss it and soon give more information on this in this issue.

I think the MIT license must and will stand. For now, we will stick to Handsontable 6.2.2.

[oscar6echo]

My suggestion is:

• Allow the custom ipywidget user to input their own license if they have one, defaulting to non-commercial-and-evaluation as handsontable officially suggests.
• Keep the ipywidget MIT license as it acts as a transparent wrapper.
• Make it clear in the docs and related blog posts.

I did exactly that for another another custom ipywidget ipyaggrid:

• section license of the doc
• medium article

This was acknowledged by the ag-grid CEO who clapped the article.

This approach is fair to the underlying lib, simple to the widget dev and allows to wrap the latest version of handsontable. It would be a pity to be stuck with the 6.x version.

[jasongrout]

@oscar6echo - the big difference here is that there would not be a open-source version of ipysheet (as a whole package) if we upgraded to handsontable 7. With your ipyaggrid, there is an open-source version.

[oscar6echo]

I see 2 cases:

• If ipysheet is embedded in a software or part of a service provided with a commercial purpose, then it seems clear that handsontable 7.x cannot be used without the pro license
• If ipysheet is provided as a thin wrapper to handsontable (with licenseKey passed through), and this fact is clearly advertised, then it seems reasonable that handsontable 7.x can be used because both commercial/non-commercial are possible and it is up to the end user to input the proper license accordingly.

So there could be 2 ipysheet versions, one with handsontable 6.2.2 for the first case, and one with 7.x and up for the second case.

Maybe it is worth asking handsontable guys.
They claim to have pondered and debated this license change a lot. And they write that their "intention is to provide free software especially to (...) scientists, (...) students" who are natural Jupyter users.

Probably they could give a quick answer.

[martinRenou]

Another solution could be to switch to a different datasheet library (e.g. https://github.com/nadbm/react-datasheet)

[oscar6echo]

Yes, if the alternative lib has the same capabilities, that would be simpler by far.
@martinRenou you're like Alexander facing the Gordian knot ! 😃

[SylvainCorlay]

I think the MIT license must and will stand. For now, we will stick to Handsontable 6.2.2.

I am totally in agreement with that.

[SylvainCorlay]

It might be worth giving a heads up to the handsontable folks about ipysheet and our intention to pin on 6.x because of their license change

• do they have any intention in maintaining a fully open-source version of 7.x in the future?
• we might drop handsontable in the future should it not be maintained as a truly open-source package.

[martinRenou]

What would you think about migrating to ag-grid?

Pros:

• ag-grid is well documented
• it supports multi-indexing by default
• it supports custom cell renderers (hopefully allowing ipywidgets in table cells)
• sorting and filtering support
• I do think it would be fairly easy to migrate.

Cons:

• ag-grid has the same economic model as Handsontable, nothing stops them from doing the same License change as Handsontable
• ipyaggrid is already there (even though it does not have the same spreadsheet approach), I would like your opinion on this @oscar6echo

[DougRzz]

There must be a big demand for a MIT licensed, community (non-commercial) led, comprehensive spreadsheet in the browser. There was an interesting project that tried to do this but it didn't take off. Here it is working with NumPy .... https://github.com/pythonanywhere/dirigible-spreadsheet/blob/master/documentation/tutorial03.rst.

Would Quantstack have the spare resources to lead a Handsontable 6.2.2 fork?

Edit: I have just contradicted myself. Quantstack is a commercial company and they could also change the license agreement of their software updates. I do think it is great when companies create a commercial product and release a 'community' edition. But ultimately it rarely gets a lot of community input because it is demotivating to devote time to a project to which the lead company will directly profit from through its commercial 'sister' product. The best Python data science packages do not have commercial 'sister' products (PyCharm is the only one I can think of). There must be an underlying reason for this.

[jasongrout]

I'll add that the phosphorjs grid we use for viewing csv files in JupyterLab has promise if it is further developed for filling the need (right now it only supports read-only cases with no user interaction like selection or editing).

[martinRenou]

I do think phosphorjs grid is awesome, it would be difficult to keep the "widget in cell" feature though. One idea for that feature would be to put the widget view on top of the canvas at the exact right position, not an easy task, but doable.

[jasongrout]

Quantstack is a commercial company and they could also change the license agreement of their software updates.

Yes, they could for their changes, but it is also more complicated overall since the copyright holder listed in the LICENSE is @maartenbreddels, though given it is the MIT license, the code can be sublicensed.

As an interesting sidenote: Jupyter has the copyright holders be something like "Project Jupyter contributors", which is meant to signify that individual contributors retain their copyright on their contributions. This makes it nigh impossible to change the license on a project itself (though of course that BSD license means that you can incorporate the files into another project if you respect the license).

[jasongrout]

One idea for that feature would be to put the widget view on top of the canvas at the exact right position, not an easy task, but doable.

You do have support for custom renderers in phosphor grid, and you can embed an HTML element into the phosphor grid canvas (and you are given a block of canvas to render into). However, it may be an interesting challenge to keep track of the DOM widgets to make sure that you aren't always creating new DOM elements every time it asks you to rerender a cell.

[jasongrout]

What would you think about migrating to ag-grid?

If it's fairly easy to migrate, this might be a good stop-gap solution (stop-gap while they keep their same model, which may be forever, or until we find a suitable replacement grid that has less chance of becoming non-free.)

[martinRenou]

cc. @mwouts as you are interested in js-datatables discussions

You do have support for custom renderers in phosphor grid, and you can embed an HTML element into the phosphor grid canvas (and you are given a block of canvas to render into)

That is awesome, I need to give it a try. Do you know if there are row/column filtering and sorting in phosphorjs-grid?

If it's fairly easy to migrate, this might be a good stop-gap solution

I agree.

[jasongrout]

Do you know if there are row/column filtering and sorting in phosphorjs-grid?

Not built-in, as that's a data model thing, not a rendering thing. @scottdraves worked on a wrapper around phosphor grid that provided that in a widget: https://jupyter.org/widgets (see the BeakerX example), and also https://github.com/twosigma/beakerx/tree/master/js/notebook/src/tableDisplay/dataGrid

[oscar6echo]

ipyaggrid is already there (even though it does not have the same spreadsheet approach), I would like your opinion on this @oscar6echo

Several thoughts 'en vrac':

• After extensive use of ag-grid first from Python via ipyaggrid, and increasingly through their vuejs component, I can say their API is impressively well designed and impeccably documented.
• But to really take advantage of the API surface, you need to (1) allow the user to write JS from Python as in ipyaggrid (cumbersome and difficult to sanitize) or (2) spend an inordinate amount of time exposing (part of) that API in Python, a losing battle.. Which is why I think that it would be more scalable to enable users to wrap react/vue/web components (built in their native ecosystems, which are progressing fast) into ipywidgets easily. @maartenbreddels agrees with the general idea and is working towards that goal. The additional burden on the mildly technical user might not be as big as it seems at first sight - I'd argue. Admittedly this goes well beyond the question ! :smile:
• My impression about JS grid libs is that to make a really good one, it requires a whole team of dedicated professionals who know their subject, make good design decisions early on, AND are around long term to pile in features that users will almost certainly ask (their have Excel in mind). Not an easy task.
• From what I understood of the ipysheet context during the (live) conversation we had this week, maybe phosphor is a valid candidate, maybe it would align several interests ?..
• Indeed ipyaggrid never tried to have cell level widgets. It's more a dataframe viewer and occasionally editor (which are then typically small sized). From my work experience, that is the bulk of use cases.
• It would be quite helpful to users (like those I see around me) to have aggrid-like dataframe renderers (all default, except maybe for a handful of simple options) in the notebook. @mwouts told me he is keen to it too.
• I see no downside in discussing the matter with the ag-grid and handsontable people directly.

[mwouts]

Thanks @martinRenou for including me in the discussion.

I came to the subject as I was trying to explore the 17,000+ indicators of the World Bank Data (see cell 16 of the itables README). An interactive table is already much better than HTML. Yet I am not fully convinced with the current display: search for 'math', and you'll get dozens of lines that are so hard to distinguish...

My experiments at itables were first made with datatables.net (which is the JS library used in both R notebooks and Shiny applications). I was then told to have a look at ag-grid, which looks really great, although I've still not clearly identified where is the limit between the community and entreprise versions (is that the grouping?).

Also, for my use case I was hoping to get the same interactive table in both Jupyter and Dash applications, in order to learn just one table object in Python, but I am probably asking for too much here! (Dash's current table component is not based on a pre-existing JS library; Plotly made the choice to develop it from scratch).

[martinRenou]

Wow, this looks very promising https://github.com/myliang/x-spreadsheet.

The pros:

• MIT license
• canvas-based, so it should be extremely fast like phosphorjs-grid
• spreadsheet-oriented, whereas ag-grid is more like a datagrid visualization library
• filtering support
• cell editing, and even formulas in cells like with excel (e.g. =SUM(A1, D3))
• visually, it looks very good (very similar to Google-sheet)

The cons:

• it is REALLY new
• there is only one person behind it
• there is no documentation yet

[maartenbreddels]

I think this is also a very attractive one, and given that spreadsheets are usually not for massive datasets, I think a DOM-based version is fine: https://github.com/nadbm/react-datasheet https://nadbm.github.io/react-datasheet/

I'd say the React basis would already (if properly done) give it nice performance.

[timkpaine]

https://github.com/paulhodel/jexcel

[timkpaine]

@mwouts for big tables with streaming or pivoting perspective will beat them all