Referencing gluon-ts and copyright

[geoalgo]

The vast majority of this repo seems to be copy-pasted from gluon-ts. It is a bit problematic as this is not really stated clearly, for instance in the README.md (which is also copy-pasted from gluon-ts).

I assume there is no ill-intent, could you perhaps state clearly which files does not come from gluon-ts? Note also, that all files that have been copy-pasted should still hold the initial copyright according to Apache license (see https://opensource.stackexchange.com/questions/5528/removing-copyright-notice-in-uis-of-apache-2-licensed-software).

Thanks!

[kashif]

Thanks david, yes no ill intent here. Ideally I would love to just depend on gluonts (and there is an issue about that on the gluonts side) and in the mean time i have tried my best to keep the license files in the headers and also included the gluonts license in here as well.

I can certainly go over it again now that the paper deadlines are over and see what I missed and would like to acknowledge any attribution. Would love your input on how best to do that?

Also note that any fixes or features I add here I try to push it to gluonts as well: https://github.com/awslabs/gluon-ts/commits?author=kashif

[geoalgo]

Thanks for your answer, I should have sayed also that it is really cool to have an option to use pytorch for TS forecasting!

I did not look at all files, it is true that some have the copyright header but a lot of them are missing it (it should be easy to fix). For the contribution, perhaps you could say something in the README that the repository is a fork of gluon-ts with some new models and the functionality to run on pytorch?

As you said, it would be great to just depend on gluon-ts for common functionalities (maybe this is possible already for i/o stuff such as datasets and evaluation?). I know about your contributions in gluon-ts are they are very much appreciated! (also read your multivariate paper, cool stuff!).

[kashif]

thanks! I'll get the headers sorted ASAP and change the readme as per your request as well.

My initial try with just requiring gluton-ts did not work out so well as the pydantic decorators call mxnet etc.

[jaheba]

My initial try with just requiring gluton-ts did not work out so well as the pydantic decorators call mxnet etc.

I think the tight coupling with mxnet is something we should work on. Ideally, the basic parts are generic and don't assume any ml library.

[ingmarschuster]

I completely agree with Jasper. Basically, almost everything thats not in the pts/model folder can be shared code between gluon-ts and pts. Maybe a good structure is one package that contains all the sharable code (say core-ts) and separate packages containing mxnet/pytorch models and having core-ts as their dependency.

[kashif]

@geoalgo can you kindly have a look now? Thanks!

[geoalgo]

Thanks a lot for doing this, hope that the backends of gluon-ts will be able to support pytorch soon!