as far as I know the spanish DNI and ceres cards are used with modules for opensc (not sure if modified or not).
OpenSC has a "plugin loader" for external, binary only modules, and if they used this code, they don't need to publish the source code for the binaries of their plugins. But if they changed opensc itself, they would need to publish that part. I haven't found a nice write-up on LGPL 2.1, how it works and what it means - GNU and other organisations are mostly concerned with GPL only, or have new papers on LGPL 3 only. from my point of view it is like this: * if code is under LGPL it is copyrighted and protected by the license. * if you use it, state that, quote the authors and the license. * the LGPL code is open and needs to stay that way. we want to improve it and you need to make sure that we still can. * if you use LGPL code, make sure it is in a way, so we can improve the code. for example it is best if the LGPL code is linked as shared library and the shared library can be replaced with a new and improved version. * better not use static linking - you would need to publish your all object code and linking instructions, so we can replace the objects belonging to the LGPL code with new and improved versions and link all together to reproduce the binary you provide, but with the improved internal. * if you improve LGPL code itself, you need to publish that under LGPL as well. code that has the LGPL copyright header stays under that license, no matter how little or much you add. * if your improvement creates new files, but not based on LGPL code (i.e. neither copied the LGPL code, nor excessive cut&paste of real code - not only function headers), then you can choose the license of your new code. if you choose to keep it proprietary, that is fine. * if you combine such new files with LGPL code into an application or shared library, again you need to provide object files and linking instructions to reproduce the work. here too the spirit is: what is open stays open! we are allowed to improve the LGPL code, and thus the total library/app you created using LGPL code, and you need to provide all means to that. * if you use a plugin interface instead for your new code, like what opensc provides with loadable card drivers etc, and you use shared linking only, then you can keep code that moved into your new plugin totally private, and only publish what is part of the LGPL library (if it is unchanged, simply copy the code and binary you used, e.g. the rpm and srpm (suse/redhat) or deb and dsc/diff.gz/orig.tar.gz (ubuntu/debian)). * evil tricks are not allowed, the license has legalese for that. for example if you applications uses a LGPL library, but validates the checksum of it, and refuses to work on a new and improved version of the same library: that is a license violation, as it would stop us from improving our LGPL library, and using it with your software. * the easiest way is this: keep the library a completly shared LGPL library, even if you modify it or add code, and publish all that as source and binary under LGPL. you can then create applications on top, that link with this library (shared, not static), and you can keep those apps private. * also send us a copy of your improvements to the LGPL library, so we can add them to our code, and create a new release with them - this will reduce maintenance of your code very, very much, and thus safe you time and money. of course I'm not a lawyer, but from my best understanding of the code and experience as open source developer and advocate, this is my point of view. Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
