Maybe the right thing to do is to make the choice of license a fundamental part of the hierarchy? That is, we could have:
Core -- all under BSD license Core.Control Core.Numeric Core.User Core.Org ...
LGPL -- all under LGPL license LGPL.Control LGPL.Numeric LGPL.User LGPL.Org ...
GPL -- all under GPL license GPL.Control GPL.Numeric GPL.User GPL.Org ...
And then we can impose restrictions like "Core can only import other Core libraries", "LGPL can import Core and LGPL but not GPL", etc.
Doesn't look very attractive to me.
Me neither. The license is meta-information about the source and should be entirely separate, so the author can change the license at will without breaking programs. Besides, it breaks our convention about organising the hierarchy by functionality. A better way IMO would be to separate licenses at the package level, so that within a package all the code has the same license. This gives a good separation between code with different licenses, while still allowing code which uses libraries from multiple sources to be written with minimal hassle. The restrictions on dependencies between code with different licenses are probably important though. Cheers, Simon
"Simon Marlow"
Maybe the right thing to do is to make the choice of license a fundamental part of the hierarchy? That is, we could have:
Core -- all under BSD license Core.Control Core.Numeric Core.User Core.Org ...
LGPL -- all under LGPL license LGPL.Control LGPL.Numeric LGPL.User LGPL.Org ...
GPL -- all under GPL license GPL.Control GPL.Numeric GPL.User GPL.Org ...
And then we can impose restrictions like "Core can only import other Core libraries", "LGPL can import Core and LGPL but not GPL", etc.
Doesn't look very attractive to me.
Me neither. The license is meta-information about the source and should be entirely separate, so the author can change the license at will without breaking programs. Besides, it breaks our convention about organising the hierarchy by functionality.
A better way IMO would be to separate licenses at the package level, so that within a package all the code has the same license. This gives a good separation between code with different licenses, while still allowing code which uses libraries from multiple sources to be written with minimal hassle.
I agree.
The restrictions on dependencies between code with different licenses are probably important though.
Actually, I don't think that either of you would like this restriction. For example, assume I write a LGPL library A and you need an extension to that library that you implement as an independent second library B linking to A. By this rule, you would *have* to use the LGPL yourself, although you probably would have preferred to choose BSD. In particular, Alastair might later (being fed up with me and my preference for the LGPL) re-implement A as A' and release A' under BSD. Now you still have B with LGPL and if in the meanwhile you accepted patches from other people into B under the LGPL, you would not be allowed to change B from LGPL to BSD (unless you get the approval of all contributors). Now, poor Alastair would have to re-implement B, too - just because he proposed this restriction ;-) Cheers, Manuel
participants (2)
-
Manuel M. T. Chakravarty -
Simon Marlow