>>> Also, there is a lot of JS frameworks and libraries that could make us >> easier the front end development. And it is good to know how to deal with >> the Apache policy using third-party frameworks. >> > We have to be very careful here. One thing is to download something to > make a proof of concept it is quite different if we want to integrate it in > our code. > > In our repo itself we can only have ALv2 based code. We do have an option > to include libraries with support functions as category B code, but for > example we cannot include a whole editor. > > When we include libraries as category B, we only distribute them as > binaries (I am aware no such thing exist for JS, but the principle is > binary). We can only make really minor adaptations to the original code, > and no way develop on it. > > Category B code can be a number of licenses, like LGPL and MPL. We cannot > however use e.g. GPL or BSD, the reason is that they limit downstream > projects from e.g. making a derivative and sell it...something we at ASF > really like when it happens. > > Another item is, I am not sure why we would need an extensive JS framework, > we do have quite many lines of JS code in our own repo. I would much more > like us to develop the remaining parts of the editor, based on good ideas > from the others, so that the whole code was Corinthia code. > > Django is not something we can use to bind client and server, due to the > license. I am the admin of a couple of servers in infra, and Django is not > the easiest or most stable framework to maintain. We should aim at a > connection between client and server, that do not rely on extensions of the > http server. > > But all that said, it still look good. > > rgds > jan I. >
Good to know, I am starting to understand the Apache ropes ;) franz
