To sign or not to sign?

Well, I'm quite scared about an LGPL, and even worse about a GPL license.
I'm developing a commercial application with OpenCascade and :

1) GPL would make that impossible
2) LGPL would force me to provide a shared library instead of static link, which I
dislike.

I also make my contributions on my free time, and I think to continue on that way; of course I don't want to publish a CAD application source code that costed (and will cost...) me months of work and has nothing to do with OpenCascade improvements itself, besides what I post about bugfixes and/or enhancements.

So, I prefere greatly to stay on OCCT license, or at least to have a double license system (OCCT + LGPL). Anyways, I still think it would be just a waste of human resources and time.

IMHO, OpenCascade did already a great effort on giving out their source code and is already doing another effort to open to a collaborative development; I don't see any problem if they'll use some of feedback I provide for making money.

Last but not least, a (regrettable) switch to a full-GPL license of OpenCascade would make me stop collaborate and stay with latest OCCT licensed code because I'd have no other choice to build a commercial app on it.

Max

Author, we understand why you feel reticent about singing the CLA. But on your side, you must also understand that asking to sign the CLA is for us a strong corporate decision. As explained here, it is primarily needed to clarify the usage of contributions in a context where we must save the assets of the OPEN CASCADE company.

If changing the OCCT license to a recognized one can help, we will consider this compromise. On the other hand, we'll for sure take into account the needs of people like Max developing commercial applications based on OCCT - especially, switching to a full GPL license cannot be an option.

So, during the following weeks, we'll study if we can relicense OCCT, and to which license.

Commenter-2

As I mentioned in the past on the .org forum, I generally agree with the spirit of CLA and already signed similar paper for the OCC team. As for the CLA on this site, probably the most significant issue I am not fully comfortable with is its perpetual nature – “…including all contributions You made prior to signing this CLA and all of Your future contributions submitted to OPEN CASCASE SAS…”. I believe, any contributor should have a possibility to opt out. He/she will still remain bounded by the license agreement (OCCTPL, LGPL whatsoever) and thus will continue to grant a *license* for the contributions. But he/she may not be willing to provide joint ownership and/or transfer a copyright, which is significantly stronger than a license. Daniel, can you address this ?

Note also a wrong web-site name in CLA.

As for the re-licensing discussion, I agree with Denis’ point on the win-win deal for the FSF/OSI license adoption. This issue has been discussed for years in the community forums (on .org, on Linux distributions,…) and we never heard any definite company position. Can it be different this time ? Can you commit for the company, Daniel ?

IMHO, LGPL would be a natural choice, especially given Salome’s use of LGPL. However, please mind its limitation (static linking, template instantiation, etc), which you might want to address. You could learn Nokia/Qt experience on providing additions/exceptions for LGPL when they adopted it in 2009. Additionally, consulting with OSS legal experts (e.g. Tom Callaway from Fedora who was participating in such discussions while ago) can be a useful option.

Commenter-3

About the perpetual nature of the CLA, what is the problem with "including all contributions you made prior signing the CLA", did you make contributions which are not compatible with the CLA ?
If it's really a problem, I expect that we can remove this article (to be validated).
As for future contributions, we could think about allowing contributors to stop their agreement, but I don't really see the added value: if you don't want to contribute anymore, you simply do not contribute. Additionally, as mentioned in the Terms of the website, you can even terminate your account.

Concerning relicensing, the expectation of the community and all arguments for such relicensing are well known.
And yes, the difference now is we want to open the development for joining the efforts.
On the other hand, I cannot commit for the company. It's still under investigation.

Commenter-2

Daniel, thanks for responding.

I was only concerned about future-looking part, not the past of course.
The point is not to stop contribution but to stop being bounded by automatic copyright transfer. License obligations would still apply, of course.

So, what about the license ? I have read the long thread on debian which Author posted in his first post and was amazed about the complications this created. It's a multi-year issue and we all will really appreciate hearing something definite. Can you help influence from inside ? Is there any other help you would need from the community to help drive this ? Please let us know.

Thanks,
Roman

Thanks a lot Roman, I keep in mind your offer of assistance. Author already did a significant proposition in the first post of this thread.

Commenter-2

Hello Author,

Here is my personal opinion about CLA and considerations you gave in your post.

When you say that the changes you submit are trivial thus not significant to be subject of copyright, do you have good (i.e. legally grounded) definition for what is significant change? Up to my knowledge, there is no clear definition to this; the outcome of similar discussions I have seen on some forums was 'only court can judge'.

We can probably rely on definition of what is legally significant used by GNU project. According to this definition, changes of more than 15 lines are considered significant; moreover multiple small changes made over time can sum up into significant change.

Thus the decision of whether change is significant becomes complicated. I believe it is much simpler and easier to sign the CLA than to analyze and discuss if changes are or will be significant.

Further, I would like to argue that the CLA is not "a contract without a compensation". Signing the CLA, you do get something in return: your changes will (hopefully) be included to the next release of OCCT, thus you will save your efforts when switching to the new release. Note that integration of changes to official version of OCCT implies certification, i.e. you will be (more) sure that your changes do not break existing functionality (and it is very likely that your change will be further improved).

When speaking about possible change of the license (to LGPL or other), note that CLA provides necessary legal ground for OPEN CASCADE to be able to do that change. If your contribution is integrated without having CLA (or similar document) signed, i.e. on the conditions of OCCT Public License, this does not give OPEN CASCADE a permission to change the license for your contribution. By signing CLA you give such permission in advance (see clause 2.a). CLA also protects your rights by promising that accepted contributions will be made available under open source license (see clause 4).

For sure my interpretation can be wrong, so please comment if you see this differently.

Commenter-5

Hello Andrey,

Since the FSF promotes copyright assignments, this definition is biased ;)
Other interesting readings about copyright assignment in free software projects:
http://www.oscon.com/oscon2011/public/schedule/detail/19242
http://lwn.net/Articles/454391/

Signing the CLA, you do get something in return: your changes will (hopefully) be included to the next release of OCCT, thus you will save your efforts when switching to the new release.

On the long term, you are right. On the short term this is less clear: when upgrading OCE to use the latest OCCT release, I spend more time fixing conflicts due to changes you made in patches I submitted than upgrading patches which have not been incorporated.

When speaking about possible change of the license (to LGPL or other), note that CLA provides necessary legal ground for OPEN CASCADE to be able to do that change. If your contribution is integrated without having CLA (or similar document) signed, i.e. on the conditions of OCCT Public License, this does not give OPEN CASCADE a permission to change the license for your contribution.

If you look at copyright holders in source files, you will find only Open Cascade and Matra Datavision. (There is a single exception in TObj, it mentions RINA S.p.A.)
So Open Cascade S.A.S claims to have full copyright ownership on the whole source code, and can do what it wants with it, for instance to relicense it without having to ask permission to previous contributors.

This also demonstrates a point in my original post, which is that our contributions up to now have been considered as not copyrightable (I doubt that all contributors did sign a CLA).

Interesting.I did not look at the OCCT source to check if some external contributions have already been integrated.

"our contributions up to now have been considered as not copyrightable": by "our", do you mean contributions from some OCE people? This long CLA discussion would be a non sense. I can't believe that, on one side, we're asked by OCC to sign a CLA because of legal issues, and on the other side that some of our contributions are integrated without even being credited.

Commenter-6

"our contributions" = patches sent by contributors to the OCC forum

I was not aware of this situation, and I doubt that all contributors to the OCC forum know about it. Most of them are certainly happy that their changes have been integrated, but a post from the Forum Supervisor would help making implicit things become explicit. Something like "Reminder: by posting a patch to this forum, you agree that it may be integrated into OCCT and that the OCC company becomes the owner of your submission". All contributors in this situation (their change were integrated in previous releases without being credited) should be notified.

Hello Tomas,

I believe we do not need to give any remainders of this kind, since (a) according to OCCT Public License (see clause 5) any modification in OCCT is licensed under the same conditions to all parties, and (b) integration of contribution to certified release of OCCT does not transfer ownership of the modification to OPEN CASCADE.

The idea to notify contributors by forum message on when their contribution have been integrated is interesting; we shall consider it. Note however that anyone can check if contribution has been integrated (or bug fixed) in official release by checking Release Notes or Change Log in Mantis.

In the new contribution workflow that we are installing each contributor is assumed to explicitly submit his contribution for integration via the tracker. He then will get automatic notification on all steps of the issue handling and will be always aware on the status.

I agree that we need to provide adequate credits to all contributors of OCCT, which we lack by the moment. This is an issue which I propose to discuss in separate thread.

Commenter-5

Hello Author,

Thank you for the links (though I should say it was not easy to read presentation materials and logs of conference meetings). I see the arguments of both sides as sensible, though the subject seems to me out of the current topic.

Note that I did not argued if having CLA is good or bad; it is a corporate decision that it is necessary, and on my side I see no point in discussing this.

My point was just to highlight that CLA does not take away your IP rights, and you get something valuable if you collaborate.

Commenter-5

Hello Author,

Let me try to answer on the points you highlighted regarding inclusion of external contributions to OCCT code, and the code ownership. Sorry for using separate post; this is just to not mix different things.

First, to make the discussion productive, we need to have common understanding on what changes are legally significant (i.e. subject of copyright) and what are not. As I see, we all have different opinions on the point. This is natural, as we are not lawyers (100% true for me; I guess for you too). My proposal is still to agree on using GNU definition. In my opinion, we can trust FSF as they really take care of such issues; after all, using GNU definition would be consistent with our intent to use GNU LGPL for OCCT.

Do you agree on using this definition?

Then I go to comments.

If you look at copyright holders in source files, you will find only Open Cascade and Matra Datavision. (There is a single exception in TObj, it mentions RINA S.p.A.)

This list is incomplete. OCCT contains also several pieces of external code covered by permissive licenses (MIT-style) that allow inclusion of the code in other software.

OCCT code also contains several contributions made by external people (on conditions of the OCCT Public License). Formally each modification in OCCT code should come with corresponding indication of the copyright of the author of the modification in the file header (see clause 4 of the license). In practice, no one follows this requirement, and hence we see no copyrights other than OPEN CASCADE in the file headers. I believe we need to address this in the future.

Note that even if copyright statements are not present in the file, this does not take copyright away from contributors, and does not give to OPEN CASCADE neither ownership of this modification nor right to use it in a way different than that defined by OCCT Public License (or other agreement if exists, e.g. CLA).

So Open Cascade S.A.S claims to have full copyright ownership on the whole source code, and can do what it wants with it, for instance to relicense it without having to ask permission to previous contributors.

It is wrong to derive such conclusion from the previous quoted sentence. As far as I know, no such claim have been given.

This also demonstrates a point in my original post, which is that our contributions up to now have been considered as not copyrightable (I doubt that all contributors did sign a CLA).

According to my analysis of the issues in Community project in our tracker, during last 10 years we have integrated 60+ contributions made by about 25 contributors. Most essential contributions (~ 20) have been provided by Commenter-3. Among others, only 4 contributions (as submitted) touch more than 10 lines of code; typical case is one-line or even one-symbol change.

If we agree on above definition of what is legally significant change, that means that only 4 contributions (apart of those made by Roman) could be legally significant. To be sure we need to check if the actual code of OCCT still contains these changes (they might have been reverted or overlapped by other changes).

For sure my analysis can be wrong; please give me a hint if you see any mistake. I also can share the details of my findings if you wish.

Commenter-5

Do you agree on using this definition?

No (FWIW I am on Kuhn's side), but it does not matter. As you said earlier, only courts can decide what are significant changes. Of course, I am not a lawyer.

This list is incomplete. OCCT contains also several pieces of external code covered by permissive licenses (MIT-style) that allow inclusion of the code in other software.
I ran this command (on Unix):
grep -ri copyright src | grep -iv 'open *cascade' | grep -iv 'matra[- ]*datavision' | grep -v Matravision
Can you please tell which pieces of code carry a different copyright? I would like to clearly identify those copyrights in our LICENSE file.

Note that even if copyright statements are not present in the file, this does not take copyright away from contributors, and does not give to OPEN CASCADE neither ownership of this modification nor right to use it in a way different than that defined by OCCT Public License (or other agreement if exists, e.g. CLA).

Here is our main disagreement. Why is there a copyright notice in all source files if it does not contain detailed information about copyright holders? It does not make sense to me.
Also I thought that part of OCC business was to seel commercial licenses. Does it mean that Open Cascade did not distribute any version of OCCT under a license different from OCCTPL? I have no problem with that myself, I only try to understand your position.

Can you please tell which pieces of code carry a different copyright?

Have a look at file Xw_save_gif_image.cxx, line 1042. I am not sure to recall easily other places (there were some more in WOK, but it is separate project now).

Why is there a copyright notice in all source files if it does not contain detailed information about copyright holders? It does not make sense to me.

This notice indicates the major copyright owner. To my understanding, this is commonly used practice nowadays. At least, looking at some source files in Qt and Linux kernel repositories I could see only one copyright at the top of the file. Is something wrong with my interpretation?

Also I thought that part of OCC business was to seel commercial licenses. Does it mean that Open Cascade did not distribute any version of OCCT under a license different from OCCTPL?

OPEN CASCADE does not sell commercial licenses of OCCT, and does not distribute it under license different than OCCTPL.

Xw_save_gif_image.cxx has been removed from official releases since OCCT 6.5.0.

OPEN CASCADE does not sell commercial licenses of OCCT, and does not distribute it under license different than OCCTPL.

Noted, thanks for clarifying. This will surely remove some misunderstanding between us.

Xw_save_gif_image.cxx has been removed from official releases since OCCT 6.5.0.

Oops! Sorry, it turns I have been looking at the current SVN working copy, and it is still there! Thank you for indicating this (to be cleaned)! It was probably the last third-party code inclusion inside OCCT, as I can not find any more...

Hi Andrey,

This is my first post to this forum, mostly because a cruel lack of free time, but I do appreciate this move towards the community and read with a lot of interest the previous posts. As Author or you wrote above, I will give hereafter my personal opinion, which is not the result of any discussion or consensus with other people from the group known as oce-dev.

First of all, "to sign or not to sign" is actually the big deal. This question has to be seriously balanced because of the "perpetual" assignement, as Roman already underlined: after the CLA is signed, it will be too late to complain. "What CLA gives" is of course part of the answer. A few unordered points:

1. I agree with you, Andrey, regarding the definition of a "significant change". Unlike Author, I do think than changing a trivial ">" to ">=" could be considered as a significant improvement if it widely impacts low level functions of the whole library, and makes them more reliable. Contributor for this change could then claim a significant contribution. I fully understand your point of view that your company may prevent such legal issues, and that signing the CLA is the safest way, for you, to integrate changes from external contributors.

2. You should have named your post to "What CLA gives to contributors". I'd also like to discuss "What CLA gives to OCC". The fact that the product quality may be improved is not something related to the CLA, and the ability to change the licence without depending upon any agreement is not a good reason. In my opinion, it only improves the financial value of the corporate asset "OCC Technology", that appears at some line of the balance sheet. Moreover, if the IP is spread over many contributors, the asset value may be considered as lower, even if the product quality (from a technical point of view) is better. I have no problem with that, but it has to be clear, so correct me if I'm wrong.

3. Regarding this first point, signing the CLA "forever" is a strong commitment (I never signed anything like that before). I can easily understand that some people sign a assignment to a company/product that is part of their business. People that have contributed to MySql for instance, improved the product and the MySql company value at the same time, but their clients benefited from these improvements. I do not like this expression, but let's call it a win-win deal: contributors do need a good product because they depend on it. Let's be clear: it's not my case. I don't work for a company developping products based on OCCT, I don't offer any consulting services and don't plan to do any (MySql was the leader on a huge and growing market, it's not the case for OCC/OCCT). So the question I'm asking to myself is: why should I sign the CLA? Do I need it?

4. Back to the "What CLA gives" and the "compensations":
4.1. "(hopefully), "(more) sure", "it is very likely that your changes": it's not a strong commitment from your side. Should I understand that it's not even sure? In other words, it does not balance the IP assignment.
4.2 changes will be included to the next release of OCCT: when? The release policy and OCCT roadmaps have to be improved. So far, I don't remember any release plan, contributors must have a clear view of what is planned in a midterm.
4.3 "it is very likely that your changes will be further improved": at OCE, most of the changes committed so far deal with portability issues: cmake builder, OSX, support for new versions of gcc, MSVC, Borland compiler etc. This fixes deal with issues reported a while ago on the OCC forum, I doubt about your ability to improve all that have been achieved.
4.4 "the integration of changes implies certification": good points. Some certified OCCT versions were released with some certified bugs, but I don't know any program free of any bug.
4.5 Back to the "Do I need it?" question: currently, the answer would be "no" (note that I contributed only a few patches to OCE, and you surely don't need me either). Another point makes me worry: it would be a mess to submit and integrate OCE patches to OCCT unless everyone signs the CLA because of the "collective" nature of a big part of this work (let me explain that in another post).

To conclude this long post, here is my current opinion: the commitments from the OCC company, as they are described on this website, are not enough to balance signing the CLA. Since there is no other possibility between "nothing" and "perpetual" (I'd love a kind of "trial period CLA"), I will wait and see before things are more clear.

Hope you won't feel offended by some of my arguments, I try to be as frank, honest and constructive as possible. Please convince me I should not be so hesitating.

Commenter-6

Hello Tomas,

I would like to discuss the paragraph #1 of your post from the practical products lifecycle point of view. I agree that even small change (your example “<” to “<=”) can increase robustness or performance of the libraries or to resolve some subset of problems (for example by avoiding of the crash at limits). I am sure, that Open CASCADE Technology contains a number of similar misprints, mistakes and errors in code. Some of them can be found and fixed using regular code analysis, but according to current practice, such problems are identified and fixed on the “case driven basis”. It means that we process the particular bug and in the frame of analysis and fixes perform this kind of modifications.
For sure, the efforts for fix even one char can be significant sometimes (even we do not touch certification process). Obviously such small changes in one character or in one if clause can be done independently by OCC developers, OCE team or other contributors (may be on the different data sets). Fixed by OCC this change will be not an “integration changes from external contributors”.

Commenter-7

We never negotiated a corporate CLA so far, since generally
contributions originate from a small number of individuals within a company.

In those cases generally the individual contributors submit the existing
CLA to their legal team for approval, and will then submit code to us as
individuals. The fact that certain contributions are authorized by the
company is subject to a separate approval process within the company
itself, of course.

My understanding is that a corporate CLA would just represent an
explicit acknowledgment that certain contributions made by the company
employees are in fact authorized. Since the standard CLA already
requires the employee to represent that the submitted contributions have
been authorized by their employers, a separate corporate CLA may be
somewhat redundant. As long as the contributing employee has a (written
presumably) authorization from their employers concerning certain
contributions, the standard Scala CLA should be sufficient.

That said, in case the legal team of a company should requires some
modifications, those can be agreed as needed, of course. At this time,
for example, the lawyers at Google are inspecting a slightly modified
version of the standard Scala CLA, as described above.

The opinions above are my own, and I am not a lawyer. However, no-one
else here at EPFL is a lawyer either :) We mainly require people to sign
the CLA in order make sure the committed code does not come with strings
attached, and to avoid legal problems as much as possible.

As long as the number of contributors is limited, therefore, the
standard CLA would do fine for us. Special company-wide agreements are
also possible, but we would have to work on a legal level in order to
make sure all is in order, and we are not particularly well equipped in
terms of legal expertise here at the moment. But we'll do what we can.

Best regards,
Commenter-8 G. Charles
Tampa personal injury lawyer

OCCT 6.7.0 has been relicensed to LGPL, many thanks to the OCC team to make this eventually happen! As promised 2 years ago, I just signed the CLA and will soon start to submit my changes to mantis.