Sun, 03/15/2009 - 18:49
Forums:
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?
Arthur
Sun, 03/15/2009 - 20:11
Hi Arthur,
I can offer hosting at SourceForge (http://sourceforge.net/projects/opencascade), if this assumes reasonable amount of efforts.
Roman
---
opencascade.blogspot.com - the Open CASCADE blog
Wed, 03/25/2009 - 12:09
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 ;-)
Tue, 03/31/2009 - 21:06
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 ?
Roman
---
opencascade.blogspot.com - the Open CASCADE blog
Tue, 03/31/2009 - 23:25
Roman, please have a look at your fix203.1.zip 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.
Tue, 03/31/2009 - 23:42
Denis,
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.
Sun, 03/15/2009 - 23:59
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
Thu, 03/19/2009 - 17:09
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.