For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings


Need to speed up your development?
Have a look at our:

Samples & Tools


Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

Patches and builds

Arthur Magill's picture

Hello All,

With the release of a source package for OpenCASCADE-6.3.0, there now seems to be a lot of progress on packaging OCC for different Linux distros. I know there are packages out there for Debian, Gentoo and SuSE - there maybe others I have missed (Fedora anyone?).

In the process, a collection of patches are being developed. However, there doesn't seem to be a central place to find these patches, or find out what they fix. Obviously it would make most sense to have them hosted somewhere on this website, but failing that, does anyone know of a good place to find patches?


Roman Lygin's picture

Hi Arthur,

I can offer hosting at SourceForge (, if this assumes reasonable amount of efforts.


--- - the Open CASCADE blog

Denis Barbier's picture

Hi Roman and Torsten, did you request approval from Sourceforge to host OCTPL-licensed source code on your SF project? My request has just been rejected, thus I am afraid that you are violating their terms of service. Or maybe you consider that your patches have a license approved by SF, but then I would like to hear your reasoning to reproduce it ;-)

Roman Lygin's picture

Hi Denis,

Thanks for an insightful question. Frankly, I have not thought from that perspective of being non-compliant with SF terms & conditions ;-). I created my project under the MIT license (which is the most permissive, just like the new BSD) intending to really distribute the materials on a free way. So, in that regard I believe it's full legal from SF perspective.

Now, am I violating the OCC license ? I've re-read it and see (par.4) that theoretically I may sublicense my work, i.e. bug fixes (e.g. under MIT). In this case I just must also license it under the OCC license. I am perfectly fine with that and anyone who downloads my modifications may use them under original OCC license. Any concerns with this approach ?

--- - the Open CASCADE blog

Denis Barbier's picture

Roman, please have a look at your zip file, there is no mention of MIT license, all files refer to OCTPL.

Moreover it clearly (at least IMHO ;-)) violates section 4 of the OCTPL because you did not include a copy of the OCTPL, and did not document your changes. Linux distributions fulfill this last requirement because their modifications are provided as patches, but you (like Torsten) ship modified source files and have thus to clearly document your changes. Anyway, this can be easily fixed.

I re-read section 4 of the OCTPL and see your reasoning about dual-licensing patches; I do not know whether I will try the same approach, it is quite hard to make sure that no OCTPL-licensed files will be put on SF, but thanks for clarifying.

Roman Lygin's picture


Thanks for a prompt reply. The MIT applies to the whole project section on SF (clearly visible on the project page). Well, formally I haven't included the OCTPL copy, this can be corrected in the future. Concerning documenting modifications I thought I did (at least in most places), anyway I try to apply rather a common sense here. As I said somewhere (here or on the blog), strict following of the license and inserting the Schedule B would be evil not good for the users as it would make the code unreadable.

I hope that with migration to LGPL this whole issue will go away. By the way, I also recommend the OCC team to adopt the copyright transfer form so that the author when submitting a contribution withdraws copyright claims. IIRC, Intel does so with Threading Building Blocks. Otherwise, the code can become contaminated and unmanageable.

Torsten Sadowski's picture

Hello Arthur,

the qtocc project has already a patch directory (occ630) in its svn repository. I just started to add the patches I have.

Cheers, Torsten

Denis Barbier's picture

IMO collecting patches would be useful only if there were a public bug tracker to know what these patches actually fix. Distromakers could then attach to the bug report the patch they include in their distribution, or add a comment telling that they do not consider this issue as a bug.