Attribution for prior works in an APIStar extension?

Hey guys, I am looking at doing a port of a couple of flask extensions into components, for use in my APIStar applications. While I have the technical know how to do this and test it, I really don’t know how to provide attribution back to the prior authors . This is really important to me because 80% of the code I want to bring in was written by other people.

Could anyone help me figure out how to properly attribute work back to the prior authors? Are there conventions in the python community? Should I do this in certain places? Do I leave out things like author from my package? Any help would be massively appreciated. I have reached out to a couple of IRC channels but everyone ignores my questions or tells me it’s not the proper forum.

Once I get this figured out I plan on putting these up on pypi.


1 Like

You can ask the authors ? Or just mention in the readme and on the pypi page and you should be good. Curious what extensions you’ll do ?

The author is unreachable and the project seems to be dead. I did just as you suggested.

I ported over Flask-Mail Check out Apistar-mail SMTP Component. I put up a simple example of incorporating the Mail component into a dramatiq actor, achieving async mailing functionality.

Cool. Any others you have in mind ?

I think we have a lot of low hanging fruit here.

Dramatiq is really nice…like I love it nice, but it uses the AGPL which could definitely turn some people off or even confuse them since the apistar_dramatiq package uses an Apache license. So naturally I think bringing Celery into the fold would be a good move.

I love Marshmallow. I have been using it instead of the type system because I think it provides better response messages on validation and I am more confident with its API. It also has an extension that can introspect your SQLAlchemy models, which you can pear down if it’s not an appropriate resource representation to share with the user. I think it should be possible to provide a Marshmallow schema as your annotation for the purposes of documenting your API. Alternatively, you could extend the type system to introspect your SQLAlchemy models and come at it from an APIStar direction. Then I would consider switching to using the type system.

I have been using a Redis backend on my own projects. I am considering spinning that off as a component for people to import and configure. I think we could do the same with Mongo and some other DB’s.

Really what I want to see is a healthy extension environment built up around the APIStar framework. In my own experience I just use the WSGI functionality. I know very little about the Async world of python and I think it could be tough having a framework that supports both programming models from an extension point of view because it could be tough or impossible to have your extensions supporting both programming paradigms.

Have you put any thoughts into extensions?

AGPL is only for internals as far as I know. As long as your extension doesn’t change them you should be fine ?

Yeah but all auto-magic-stuff come to an end (have for me at least) sqlalchemy<->marshmallow.

I mostly want fast/working-building-blocks and if I had to use marshmallow/orm/etc & stuff I’d use another framework. (wheezy)

So if I had free time I’d make core-better(type,routing etc). Extensions don’t provide a big thing for me (flask-sqlalchemy/alembic does and some few).

The author of the dramatiq package asserted in Episode 141 of Podcast.__init__ that by using import dramatiq in your project you are obligated to abide by the terms of the AGPL. I am no lawyer but when I read the license and from watching the Pycon youtube videos, I’ve come to understand that the AGPL requires you to provide the source code for your application even if you don’t distribute it. Meaning that by having a user interact with your web application(which uses dramatiq) you are obligated to provide that user with the web applications source code, because it is derived from an AGPL work.

An interesting thing though is how other companies view the AGPL for example MongoDB. They assert that even though your application interacts with a Mongo DB AGPL database you are only required to contribute back the changes to Mongo that you make, and that the Apache licensed connectors they provide “firewall” your work from an AGPL infection. What is confusing though is that the apistar_dramatiq which was written by the same author of Dramatiq was released under Apache 2.0. Which according to Mongo DB logic means that if that is your interface to dramatiq then you should be ok.

I have been going batty over this but can’t seem to find any court precedence that took the AGPL and applied and am not coming up with much. I did find this article that asserts the same thing that AGPL sharing requirements only kick in if you modify the program, so if I went in an forked dramatiq and modified it then I would need to provide that modified version to users.

That’s how I know it to by mostly just reading online. You modify mongodb, you send patch for mongodb, not your whole application. So they get back stuff that you do to mongodb, they don’t care about your node.js/php/flask app.

I am starting to come to the same conclusions.

There was a case recently Artifex v Hancon in CA where the GPL was under review. It was going the direction that the GPL constituted a contract. A bunch of the Free Software Foundation people were gushing over the particulars of the case, but they all neglected to mention that it was settled out of court back in December 2017. Which means to my knowledge that no Article III court precedent could have been established in regards to the GPL. I can only find one case where the GPL seems to have been tested in the US Jacobsen v. Katzer. It appears to have only determined that Open Source can make a copyright claim.