PKCS#11 header license - replacement headers

On 12/9/06, Marcus Brinkmann <marcus.brinkmannruhr-uni-bochum.de> wrote:
> Well, two reasons: We like the GNU coding standard, and
I toyed with
> the idea to just change the API so that we could make
our own code
> consistent.  But I haven't gotten around to do that yet
(that's
> because I wrote the code against the original API first
before writing
> the header file replacement).
>
> The other reason, again of questionable value, is that
it strengthens
> our copyright on the file and makes it more of a work
distinct from
> the RSA header file.
>
> Two bad reasons don't necessarily make a good reason,
but I still
> kinda like it that way.  Although I have to admit that
the macro
> definitions are gross!

I think that a program should be compiled using the free
version and
the proprietary version, I don't mind that CK_RV is declared
as
unsigned long int and not CK_ULONG, which in turn declared
as unsigned
long it... As long as CK_RV is provided.

The same is for every other type of the interface. I don't
think that
modifying the structure member names is a good approach.

I don't think that PKCS#11 spec can fit into GNU
conventions... And I
don't think that just renaming variables/types changes the
copyright...

So I don't think that these reasons apply... :(

But it is your call... 

The current state is good enough to be usable.

Best Regards,
Alon Bar-Lev.
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

Hi,

At Sat, 9 Dec 2006 22:33:24 +0200,
"Alon Bar-Lev" <alon.barlevgmail.com> wrote:
> > Two bad reasons don't necessarily make a good
reason, but I still
> > kinda like it that way.  Although I have to admit
that the macro
> > definitions are gross!
> 
> I think that a program should be compiled using the
free version and
> the proprietary version,

I agree that this is useful to have, if you want it, and our
header
file should support that in the compatibility layer.

Thus I have changed how the compatibility layer works. 
Selecting
CRYPTOKI_COMPAT now does not simply add a compat interface
to the "GNU
interface", but instead it replaces the GNU interface
completely with
the official API.

This works by #define'ing the GNU names to the PKCS#11 names
temporarily.  As we control the content of the header file,
this
should not conflict with anything outside of the header
file.  The
only way this could conflict is if the user already
#define's some of
the GNU names that we temporarily redefine before including
the header
file.  I think that this would indicate bad style.  Do you
think this
could be a problem?

> I don't think that PKCS#11 spec can fit into GNU
conventions... And I
> don't think that just renaming variables/types changes
the
> copyright...

I agree that the PKCS#11 spec has other idiomatic structures
that make
it unfit for GNU convention, but I am just sensitive to
naming.
Changing to the new naming will make my other code more
readable for
me, and I think that it is worth it.  I hope that with the
new
compatibility layer we can find a compromise that suits both
types of
uses.

I agree that just changing a variable name does not affect
copyright.
But the two interface layers (compat/GNU) force some other
restructuring that can potentially affect copyright.

> So I don't think that these reasons apply... :(
> 
> But it is your call... 
> 
> The current state is good enough to be usable.

Please let me know what you think about the new
compatibility layer.
I looked at gcc -dM to check that it does not leak any
definitions
that shouldn't be there, but I only tested it with Scute so
far.

Thanks,
Marcus

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel