Am Sonntag 20 September 2009 17:25:59 schrieb Martin Paljak: > Hmm, that is an interesting idea. It would also have to include scconf > which currently is distributed separately, but then again is also used > by other software like pam_pkcs11 for example.
yes, but don't they use a copy of the code or something? oops, I wasn't aware we had libscconf.so.2 as standalone library. hmm, not sure what is best for pam_pkcs11, but if there is only one other user, why don't we make it internal too? after all scconf is neither well documented nor maintained nor has seen any development in years, so a static copy shouldn't make anything worse. from building pov I guess it won't be hard, we need either have make create a dir/libdir.a and then link all of them into opensc-pkcs11.so or create that one directly from dir/file.c files. > It can be a step-by-step move. We declare PKCS#11 as THE interface, > combine *.export files for compatibility, then gradually refine the > API and headers (which should then only be used by OpenSC tools) lets say, the question is not if we want to promote PKCS#11 (I think we all do), but if we want to break openssh support for opensc completely. we could keep the old api somehow exposed it we want openssh to keep working. I would favor that, as openssh is the most important app for me. > > * keep license LGPL 2.1+ or change to LGPL 3.0+? > > What are the differences and why? LGPL3 is a GPL3 spinoff, so it has tigher rules on patents etc. I don't think we need to switch, but if we want to, then a new major version is a good time to do that. > > * keep allowing drivers with no source or mandate changes > > to libopensc be LGPL'ed (or compatible)? > > I'm not an expert but to my understanding all libopensc modifications > that get distributed must come with source? no, only derived code needs to be published. for example changes to our code need to be published. but if you write a new driver on your own without using any driver as blue-print, then you have the option to keep your code proprietory and not publish it under LGPL. but if we remove the interface for loading plugin drivers and make most API internal, we make a statement that new drivers are also considered changes within the library and thus derived work, and we expect people to publish their code under LGPL. its similar to the kernel developers marking export symbols as GPL with the statement: if you use those symbols, you derive from the work we did creating the whole framework and thus we expect you to publish your code under GPL. well, I'm not a lawyer, but at least we can send signals if we continue to say "use the lib however you want, changes to non-core can be kept proprietory" or "any change within the lib is considered derived work and we want it to be published under LGPL." Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
