Comments (7)
Yep, all contributors have agreed to the CLA
from blankly.
Great question and I'm glad we're getting a chance to address it!
We chose LGPL because it strikes a clean balance between protecting our code and allowing people to use it in their closed-source code. Just like the organizations you mention, we're hoping that we can move to Apache 2.0 as we grow & establish ourselves in the scene. This is similar to how QC moved from closed source to Apache).
Our interpretation is that importing external python libraries into your code is permissible under LGPL. From wikipedia:
"Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, a statically linked library is allowed if either source code or linkable object files are provided."
Because we are writing valuable code that provides more than what other paid services provide, we have to start out by protecting the library before steadily loosening those restrictions. The hope using LGPL is to allow users to use our code in a closed source environment, but require them to open source any changes made to the package itself. This allows us to improve our own library.
This is not legal advice.
from blankly.
How would LGPL protect your code?
What it will do is others have to publish their changes but when it comes to merging the code into your code base you would have to get the code licensed (through a contributor license agreement) otherwise you would loose the control over the code as now you would be forced to comply with LGPL and you cannot even relicense and change the license without everyone's permission . If you plan to provide tightly coupled infrastructure around the open source code this might become problematic also.
Also people in the financial services industry would more concerned with using libraries which are not permissive.
In my opinion your best bet is to go all out and increase the number of users, broker integrations, etc., regardless how they use it.
from blankly.
You're right, we've had to balance all of this with the contributor agreements that come with the space.
With our increasing user base and the interest of contributing, this might be sign that we should migrate to Apache now before the agreements get more complicated.
from blankly.
I see there are few merged PRs from 3rd patties. Are you keeping a Contributor License Agreement? Otherwise these merged code does not belong to you but licensed to you under LGPL. This would become very problematic for you and a company if you have to make changes on the hosted versions then time comes to move AL 2.0.
from blankly.
Any news on transitioning to Apache 2.0?
from blankly.
I think we're going to stick with LGPL, I think it fits our goals and the industry the best.
from blankly.
Related Issues (20)
- Append bar to history raises either a TypeError or a FutureWarning HOT 2
- Binance futures not working HOT 7
- IndexError: list index out of range HOT 1
- state.interface.history duplicating prices HOT 3
- Title:Trailing Stop with limit orders in Blankly Finance paper trading environment HOT 9
- Implementing Upbit Exchange HOT 1
- Cannot run blankly login HOT 6
- Alpaca not working with crypto HOT 1
- Integrate Blankly with a timeseries database HOT 1
- Accept in memory data for backtest
- strategy.backtest without `to` argument should infer `start_time` and `end_time`
- KeyError: 'bidMultiplierUp' HOT 3
- Alpaca Cryptocurrency error(maybe just an alpaca related data error) HOT 1
- Inconsistencies in asset visualisation HOT 1
- Ow
- Innaccurate Historical Data HOT 2
- bar_event squashes price_event price HOT 1
- `state.interface.history` not returning history with correct time intervals
- `ignore_user_exceptions=False` parameter in `strategy.backtest` doesn't work
- Error installing blankly. 'ti.pxd' not found HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from blankly.