Log In
Home
04/19/2016
Offline
The website states the following; (http://opcfoundation.github.io.....TStandard/)
“Note: Dual license applies to this repository only; GPL 2.0applies to all derived repositories (for example 'forks').”
Is this for a fork on Github or other public repository? Or all repositories?
Here is the hypothetical situation.
If we find a bug, and need to make a fix till it is fixed in the “mainline” repository, are our assemblies now considered GPL V2.0?
That is if we make the fix in our own private repository.
Of course we would submit the bug and potential fix.
If it is GPL, what are our options?
Best regards,
Tim
05/30/2017
Offline
Fixes can be tested on private forks with no concern.
Once you have tested the fix you should submit it back to the OPC-F via a pull request.
When a fix is part of a pull request on the main repo then RCL applies.
Ideally the OPC-F would merge the pull requests quickly but there could be delays which is why the date of the pull request will be used as the date when the code was added to the main repo.
04/19/2016
Offline
Hi Randy,
Thank you for your response.
Another clarification question about the RCL license.
"Regarding deployment, under the RCL your changes, bug fixes, extensions, etc. must be made available to the community when you Deploy in any form -- either internally or to an outside party.
Once you start running the software you have to start sharing the software. Further, under the RCL all derivative work components you author including schemas, scripts, source code, documentation, etc. -- must be shared. You have to share the whole pie, not an isolated slice of it. The authored components you must share are confined to the original module licensed (e.g. SDK, stack, wrapper, proxy, utility, etc.). You do not need to share any additional authored components that you create that utilize the licensed component. This license is meant to be friendly to commercial software vendors that must protect the IP in their code. You are not expected to share your proprietary source code that makes use of the module(s) licensed under this agreement."
If we just use the SDK as is, not modifying the SDK, then there is nothing for us to share.
If we create a subclass of one of the SDK's classes, then we would share that code back?
If we create a C# class extension of one of the SDK's classes, then we would share that code back?
Following your earlier statement for a fix, then when the pull request is merged, then our code is then licensed under the RCL?
Any code we use from the samples is covered under the MIT license. So any code we use from the Samples fall under the MIT?
05/30/2017
Offline
The clear intent of the RCL license is to ensure fixes to the base libraries are given back without compromising members own IP rights.
The rule of thumb should be: if you change a file distributed by the OPC-F then that change must be given back. If you extend the library with subclasses or helper functions then that does not need to be given back unless the changes require your new code to be compiled into the same library as the OPC-F code. If the latter then the new code is too tightly coupled to be considered a true extension.
Once you submit the pull request the code is considered RCL because that fix is available to all users of the OPC-F libraries even if it is not merged so it fulfills your obligations. The OPC-F will choose to merge or discard your fix on its own schedule and that should not have any impact on your ability to ship your product.
Code marked with MIT has no strings attached other than keeping the license notice intact.
1 Guest(s)
Usage Policy