Hi everyone, It's been going through my mind whole day on how to solve the solution to the licensing stuff we are faced with on daily basis.
I will give an example of my solution using commons-graph, that just came up with a lgpl depency. The dependency is on nsuml and is weaved into commons-graph using imports. Since apache uses a flexible license, we should weave differently. The gpl stuff should import us. Since we are not committers on all projects we (would like to) depend on, there is an "in between" solution. (already suggested this this morning on some list though, but now from another perspective). We can create an interface that will be exposed in commons-graph and make an implentation from the nusml perspective and respect their license. This way the implementors will depend on us. I will call it reverse dependency strategy" You probably think this is not much different from what happens with ant. This is true, but somethimes you want it the other way around and keep that implementation in the cvs repo's (not talking having jars in the repo's though though) Applying the current rules at apache are (as far as I picked them up ==> which means in respect to this idea) - No GPL stuff in cvs, which I intepret also as have GPL in our cvs repositories, even if written by ourselves. - Since we cannot depend on GPL, the possibilities are limited (eg the ssh implementation being discussed on ant-dev) and issues with that are taking up valuable programming time or we must make a solution ourselves with costs also valuable programming time. >From an fsf.org point of view : - If apache wants to use gpl stuff they have to change their code to gpl. What needs to be done to make sure above is not needed (NOTE: GPL means in this case : incompatible with apache!, it saves typing..) - Make interfaces if you need gpl stuff. - Write an implementation on that interface and conform to licensing of gpl - Put that source in a seperate structure (eg a subdirectory of the project) on apache cvs, so we don't accidently infect our main code and compile it as part of the regular build , which needs us to have the main code relicensed (not a real issue, since we can seperate them out in case that should happen, just seeing it happen is difficult) - Distribute it seperately from the main distribution (like the ant-optional did in in the past). Even though I think it is possibly to dual license the implementation so we can distribute the implementation in our apache releases... - If we want to have a dependeny on a package, check the license and see if it is not on the allowed list and start seperating. - Apache has to make the decision to have other licensing allowed in their repositories, probably with the assurance that apache is the full copyright holder of the code that is in the repository (so not talking about cvs import <from gpl cvs repo on sf), but written implementations for scratch, for the benefit of the project it is concerning. Why the hell do we want that : - Somethimes we want to make stuff ourselves. Esp with tools like Ant and Maven, which benefit a lot of integration with other tools, cannot do so currently in their repositories, which in some cases can be preferrable to setting up a project on sourceforge(t). - The rest above :) - The words on fsf.org "We strongly adivice you never to choose an apache license for any software". I won't say more about this, but it kind of pissed me off and started me thinking about solutions to these everlasting discussions :) Why don't we want it (or things to really thing about..): - I have to much "I think". This is mainly because I am not a lawyer and though reading the fsf.org stuff clearly - Keeping track that it goes allright - We need to send floppies with the sourcecode if people request it, or always include the source in the distro that contains the gpl part, so you don't have to send floppies around. - Extra licensing may confuse people (and extra downloads too). - Hard to get oversight. - Apache needs to change rules I guess and this probably needs a lot of research by legal people. Hope this gives some valuable input for discussion, which let us allow these kind of things, so we don't have to move that specific stuff to sourceforge and we can stop having the monthly licensing discussion (already cleared up a lot though by statements from the board), but this can make life a lot easier. Pleas read below : <DISCLAIMER> This proposal is not a real proposal, since I don't mind it's outcome, but since this proposal clearly focusses on solving, it has an intent to improve something that is, in my opinion, not broken at the apache side, but the Apache side is the only side it can be fixed through. I have tried to oversee any issues at the ASF / Board / PMC and legal level, I cannot guarentee that I covered them all, so I will not ask the asf to have a go at this, since I may missed some major issues. It will be appreciated however to get feedback on this, saying "we are going to look at it". Although I think this approach can be used in ANY environment (commercial, etc), I strongly advice to double check this! </DISCLAIMER> Mvgr, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
