Licensing about gpb HOT 10 CLOSED

Oh. My main objective with the LGPL was to have the code open-source, and make sure it stays open source (eg no fork being turned closed source). I have to read up on the different licenses, and what options are available. (input, especially for what options are available, are much appreciated.) One alternative might be dual-licensing.

from gpb.

As I'm sure you know, no license will prevent gpb from being used internally at a company or by an individual in a closed-source fashion (except, maybe, the AGPL). Licensing will only affect how gpb is included and distributed as part of other software.

Your suggestion of dual-license is a good one. gpb could be LGPL licensed (or AGPL) when used with closed-source software, and given a more permissible license (such as Apache or MIT) when used with OSS software.

from gpb.

Yes, I know, sorry I was a bit too cryptic. After having read up a bit, I can accept Mozilla Public License 2.0. It appears to be compatible with Apache 2.0, and Apache says it can be used with some restrictions in an Apache project. An important issue as I see it is that MPL-2.0 requires any modifications of the source to be made available, which Apache 2.0 does not. Dual-licencing doesn't seem the right way either to ensure that the (modified) source is made available, so I'm no longer seeing that as an alternative. Would going MPL-2.0 be an ok way forward from your point of view?

All this is of course if all contributors agree. I can administer mailing them to ask.

Also, somewhat related: as I'm sure you've noticed gpb can generate code that has no run-time dependency with gpb, I'd expect the license situation might be more like that between eg a C compiler and the executable it produces. One would not normally include the C compiler as part of the project, or require it to have the same license as the executable. This is somehow different for you with gpb?

(Also related to this is for the upcoming proto3 syntax, where the (new) Any might require run-time support for on-the-fly unpacking a blob as a message given an url to its .proto file. But this is another problem, for later, yet a bit related to the current possibility to generate code without run-time dependencies to gpb)

from gpb.

MPL 2 would be great, I appreciate your willingness to look into this tedious but important issue.

as I'm sure you've noticed gpb can generate code that has no run-time dependency with gpb

I did notice that, but didn't think of the implications for licensing. This also would be a great work-around if you'd like to keep LGPL licensing... plus you wouldn't have to track down all your contributors 😄

Do you know if there is any measurable performance difference between the #field{} generated code and the code that uses proplists? I'll try out your benchmarks with that as well.

Thanks!

from gpb.

Do you know if there is any measurable performance difference between the #field{} generated code and the code that uses proplists? I'll try out your benchmarks with that as well.

No, there should not be any measurable performance difference. There #field{} representation is purely for introspection purposes. These introspection functions are not used during encoding or decoding in the generated code.

I did notice that, but didn't think of the implications for licensing.

Me neither, actually, up until just now :) I'll meditate a bit more over licensing, assuming there's nothing immediately stopping you from using gpb. Again, details of the implementation for the Any type might also have implications, so I'll keep this open for a while until decided.

from gpb.

Hey Tomas -

I've modified how riak_pb uses gpb in my experimental branch, and it's working great. So, there's no need for a license change. I appreciate the dialogue we've had about it, and thanks again for maintaining this library.

Have a great weekend!

from gpb.

You're most welcome! Interesting to learn about riak_pb. And a nice weekend to you too!

from gpb.

Hi Tomas,

Really like your work, huge thanks for contributing it to the community.

About that licensing issue - one of our guys pointed me to this question in GPL FAQ. I am not a lawyer, but it feels it might be a good idea to specifically add such clause to your license and potentially add similar message in files generated by GPB to allow their usage with any licenses. Please let us know what you think.

Thanks,
Pavel

from gpb.

@ph07

but it feels it might be a good idea to specifically add such clause to your license and potentially add similar message in files generated by GPB to allow their usage with any licenses

Hehe, there's already a similar paragraph in the license and the reason I originally included it was in fact because I was thinking about the issue with Bison. It might be worth knowing that the code generated by gpb does, by default, have a compile-time dependency to gpb: it does -include("gpb.hrl"). and the introspection functions return records defined in this file. But it is possible to avoid this dependency altogether, either by using the defs_as_proplists option, or by compiling with the maps option (or just the defs_as_maps option), and then the generated code is totally free of both compile-time dependencies and run-time dependencies to gpb itself.

from gpb.

Saw the updated licence, it clears the issue. Thanks, Tomas!

from gpb.