Wed, 02/25/2009 - 20:12
Quoted from introduction text found at
http://www.opencascade.org/occ/license/
In short, Open CASCADE Technology Public License is LGPL-like with certain differences. You are permitted to use Open CASCADE Technology within commercial environments and you are obliged to acknowledge its use. You are also obliged to send your modifications of the original source code (if you have made any) to the Initial Developer (i.e. Open CASCADE S.A.S.).
The last sentence is clearly wrong, OCTPL 6.3 does no longer
require changes to be sent back.
Can someone please update the page above to remove this phrase?
The other differences seem also to be void: LGPL can be used
within commercial environments, and I do not see how OCTPL
6.3 differ from LGPL 2.1 section 6 with respect to
acknwoledging its use.
To me, OCTPL 6.3 is similar to LGPL 2.1, except that it uses
different words and a different name, which is very
inconvenient when someone has to wonder whether this license
is compatible with another license.
Can someone from the dev team please tell me what are the
real differences between OCTPL 6.3 and LGPL 2.1, and if
there are only cosmetic differences, would you consider
relicensing Open Cascade to LGPL 2.1 to ease integration of
Open Cascade with other software?
Thanks for your consideration.
Wed, 02/25/2009 - 22:54
Denis,
As I mentioned earlier in my blog ("License to kill. License to use"), this wording has been designed by me and my colleagues so let me comment here.
The second and further sentence does not describe *differences* with LGPL what I agree can be assumed by the reader. They rather explain key aspects of the license. The obligation to send fixes is probably reinforced original statement that any modifications are licensed under the same license and must be provided to any third party (including Initial Developer) on a free of charge basis.
I do believe that everybody's benefit the license should rather be superseded in favor of something existing and recognized by OSI (www.opensource.org). However OCTPL is more permissive than LGPL. For instance, LGPL requires dynamic linking while OCC is fine if linked statically. LGPL 2.1 is known to penetrate into the user code through inlines and templates (the issue resolved in LGPL 3.0), and OCC does not have this viral aspect.
If there are people around here who also support adoption of a standard license, please speak up in order to help the development team to estimate importance of this. Go add your message to this thread. If you can provide reasonable arguments why you think it's important, that will be even more valuable. If not, just add "+1" or alike.
Thanks.
Roman
---
opencascade.blogspot.com - blog on Open CASCADE
Thu, 02/26/2009 - 00:06
Roman,
First of all I had the feeling that OCTPL did change over the years, I remember having seen this request of sending back patches in previous versions, but I may be wrong, I do no more have old license files.
Now about your answer, I disagree with your first paragraph, OCTPL does *not* force me to send changes back to Open Cascade dev team, so the introductory text is clearly wrong. There has been recently some interest from Fedora folks to provide opencascade packages, and I believe that this statement made them consider that opencascade is not suitable for them. This statement has also been discussed by Debian at http://lists.debian.org/debian-legal/2006/06/msg00222.html
I have other questions about your answer, but in fact my main interest is to know whether OCTPL is compatible with GPL. This is not obvious, since licenses use different wordings, and some people argue that if the intention of the OCTPL is to force sending fixes back, this is clearly incompatible with GPL.
Thanks!
Thu, 02/26/2009 - 08:56
Hi Denis,
Thanks for further comments. I don't think the license has changed over past few years (I have older copies and can compare if this is important).
Correct, the license verbatim does not force you to send fixes back to the Initial Developer upfront. What it does force you however is the same what GPL and LGPL do force you to do - to license your modifications under the same license and provide them free of charge to anyone who might want to get such fixes (including the Initial Developer). You may not hide your fixes and refuse to provide them - that would be a clear violation. The question how enforceable this condition is goes beyond OCTPL itself and is common for any public license.
Your reference to Fedora and Debian case is a good example of why OCC should rather be licensed under some boilerplate license. I strongly believe that if OCC did that it would open a much wider door for it into the Linux world, including taking advantage of being part of OS distributions.
Regarding compatibility with (L)GPL. I do not have a clear understanding of criteria to consider the license to be compatible, please share if you do. I base my knowledge on the FSF resources, first of all, a list of compatible/incompatible licenses - http://www.fsf.org/licensing/licenses/index_html. The above list of incompatible licenses sometimes elaborates why a license is incompatible, and reasons are very different (e.g. CPL/EPL is incompatible as it prescribes a choice of law). I can't say what can make OCTPL incompatible with (L)GPL. For instance, it has various weird requirementы to specially mark up your modifications with Schedule A and B, etc (see section 4). The latter is really awkward as it would have made the source code harder to read and comprehend should it have been contaminated with such markups. Does it make it incompatible ? GPL 2.0 for instance, does also require modifications' time and author name.
So, devil is in details. The only reasonable way out imho is in adopting a recognized license. Whether to choose a license compatible with (L)GPL can be up to the OCC team but this would be a big step ahead anyway.
Hope this helps.
Roman
---
opencascade.blogspot.com - blog on Open CASCADE
Thu, 02/26/2009 - 11:58
Roman, if you believe that OCTPL has not changed for years, I trust you; my feeling was surely wrong, it does not matter much.
The compatibility with GPL is simply that a derived work cannot impose restrictions which are not in GPL, see section 6. So if someone reads the quoted introductory text to the letter, OCTPL is not compatible with GPL. The question is: what are Open Cascade intentions? Either they really want to force us to send back patches, and this is their right, or they want to be more permissive than is written in the introductory text, but then this text could be clarified to avoid confusion.
As you mentioned, there are other differences, and it is indeed awkward to determine whether there are restrictions which go beyond what is in GPL, this is why things would be much clearer if OpenCascade was licensed under LGPL 2.1. (Or any other license listed on the FSF site, I picked this one because I believe that OCTPL is identical to LGPL 2.1. As you can see, I am not convinced that OCTPL is more permissive than LGPL 2.1 ;-))
Thu, 02/26/2009 - 18:39
Hi Denis,
The license text must prevail any descriptive text anyway, it could be good to either rewrite it or remove at all.
Regarding LGPL 2.1 vs OCC (which is more permissive) debate, I believe we are looking from different angles. Your point is that LGPL does not enforce mandatory sending modifications back (though it does require modifications are LGPL'ed) and in this sense is more permissive. But as we already discussed, OCC equals LGPL in this regard (it's an explanatory text that overstates the requirement). My point is that OCC is more permissive in aspect of allowing static linking and not contaminating the user code through inlines and templates.
Roman
---
opencascade.blogspot.com - blog on Open CASCADE
Thu, 02/26/2009 - 13:54
+1
I've been trying to get OCC-using free software integrated into Linux distributions. Even though the software itself is licensed under LGPL or similar permissive free software licenses, the dependency on OCC has made it effectively non-distributable by major distributions.
As you say, this may not be because of the actual contents of the OCC license, but because of the confusion on what it actually requires. Switching to a well-known license would certainly fix this and increase the adoption of OCC.
Teemu
Thu, 02/26/2009 - 18:40
Good example. Thanks Teemu.
Thu, 02/26/2009 - 21:26
Roman,
We've had requests for a while now from people trying to include items under the OCTPL in Fedora, and we've had to tell them all no. We had our lawyers (Red Hat Legal) do a license review, and this was their feedback:
A couple of things are of concern:
1) In the paragraph preceding the license terms itself, they say:
You are also obliged to send your modifications of the original
source code ... to [Open CASCADE].
That sort of requirement was traditionally considered non-free by the
FSF . Strangely, though, we don't see where in the "actual" license
itself it supports this statement, which appears to be a summary of
what the license requires. So that's also a concern even if there
weren't an argument that the requirement is non-free: is this a
requirement or isn't it? (which perhaps itself can be said to make it
non-free)
Cf.
http://www.mail-archive.com/debian-legal@lists.debian.org/msg38064.html
(suggesting that OpenCASCADE told Debian that the preamble is binding?)
FWIW, if I'm not mistaken Debian has classified packages using code
under this license as non-free.
2) Section 7 says:
You may choose to offer, *on a non-exclusive basis*, and to charge a
fee for any warranty, support, maintenance, liability obligations or
other rights consistent with the scope of this License with respect to
the Software to the recipients of the Software ....
Except for the part delimited in asterisks, this would be free
though annoying. But limiting this permission to "a non-exclusive
basis" is bizarre. Why can't someone choose to offer support exclusively to
customer A but not any other customer? A fair number of FOSS licenses
have these upstream indemnification clauses, but we don't think we've
ever seen one limited to "non-exclusive" offerings of support and so
forth.
Moreover, if you read sections 6 and 7 together, you get the sense that
they're taking "may choose to offer" in a very literal sense, implying
that 'you only have the following very limited permission to offer
services surrounding the software' --
contrast that with, say, GPLv2 which says "you may at your option offer
warranty protection in exchange for a fee" -- this is intended to
clarify what ought to be obvious. In other words, in OpenCASCADE any
sort of services offering relating to the software is, in their view, a
forbidden 'additional term' unless it's covered under section 7.
*****
Based on those issues, they determined that the OCTPL is non-free. In Fedora, we only allow software under free licenses, because while all Free licenses are Open Source, not all Open Source licenses are free (and some Open Source licenses are really really bad).
You'd make a lot of people happy if you resolved those issues, but you'd make me even happier if you guys dropped the license altogether and moved to an existing Free Software License. Fedora has a very long list of them here: https://fedoraproject.org/wiki/Licensing
Thanks in advance,
Tom Callaway, Fedora Legal
Fri, 02/27/2009 - 12:10
Hi Tom,
Great to see an Open Source legal here on this forum ! Thanks a lot for pointing out particular items, this is really helpful. As I said above, the preamble should not be considered as a legal text and the license should prevail in any place they contradict. However, since I am no longer an Open CASCADE employee this only reflects my personal opinion, even I co-authored this text some day.
I believe that the only real progress can be towards adoption of a standard license. May we take advantage of your presence and ask some questions to hopefully facilitate its choice ?
Here are the most significant criteria the license must meet:
- For user benefits:
o Being not viral – the license should allow proprietary licensing and protect the user from infecting his/her code regardless of the way OCC code is used: dynamic (shared) linking, static linking, inserting headers, using macros, templates, etc;
o Allowed to combine the code with GPL, LGPL, non-copyleft, proprietary licenses (not necessarily in one application). Does this limits the scope to GPL v3-compatible licenses only ? What must be done to enable this if non-GPL compatible license is chosen (e.g. add explicit exceptions) ?
- For OCC:
o Ensure that modifications are licensed back under the original license on a free of charge basis. How could this requirement be enforced (as the current preamble overstates it)?
In your opinion, what are possible options for a license to meet those major (though not the only) requirements ?
Thanks.
Roman
---
opencascade.blogspot.com - blog on Open CASCADE
Mon, 03/02/2009 - 21:11
Hmm, not sure why the forum didn't notify me of the reply... anyways, sorry for the delay.
The biggest problem is that you want the licensing to be "not viral" and still "ensure that modifications are licensed back under the original license". These two clauses are almost always mutually exclusive. The closest thing to what you want would be to add linking exceptions to the GPL, like MySQL does, but you need to be careful, as it is very difficult to do what they have done and still be considered a Free license (http://www.mysql.com/about/legal/licensing/foss-exception/). Several attempts at similar schemes have failed to be considered Free.
Another solution may be a dual license. Offer under LGPLv2+ (it is widely considered to be pretty compatible with other license), and as an alternative for proprietary programs wishing to build against the Open Cascade bits, a proprietary closed-source license available from OCC for a fee. This is similar to Red Hat's Cygwin licensing model (http://www.cygwin.com/licensing.html).
I would suggest that the OCC talk to the Software Freedom Law Center, they give free legal advise around free licensing for software, and can provide more indepth assistance.
hth,
~tom
Wed, 03/04/2009 - 23:37
Hi Tom,
Just a small clarification. By being "not viral" I meant that the user can still use his proprietary license for his code, but not for the modifications to original library. LGPL is indeed an example of such balance - user's code may remain proprietary while modifications in the LGPL'ed library are licensed back under LGPL.
Yes, it seems that LGPL became the most favorable and reasonable choice here.
Thanks again for your professional insightful comments, which have been of great help.
Roman
---
opencascade.blogspot.com - the Open CASCADE blog
Sun, 03/01/2009 - 06:42
"However OCTPL is more permissive than LGPL. For instance, LGPL requires dynamic linking while OCC is fine if linked statically. LGPL 2.1 is known to penetrate into the user code through inlines and templates (the issue resolved in LGPL 3.0), and OCC does not have this viral aspect."
Couldn't this be resolved by using the LGPL and adding an exception something like "As an exception, you are allowed to use the inlines and templates in OCCT with non-LGPL'd code. Neither that nor static linking will infect your code with our license."
I, too, would *really* like to see OCCT released under a "standard" license. I think that it would help OCCT a lot.
If the OCCT team has questions about modifying their license or using the (L)GPL with an exception, why not contact FSF Legal at licensing@gnu.org ?
Another alternative is to provide a different license for paying customers. Non-paying customers get the (L)GPL version, while paying a modest sum allows the customer to legally statically link, and frees them from the (L)GPL requirement to provide source code to their customer. Or simply dual-license without the fee, like Mozilla (Firefox)
Mark
Wed, 03/04/2009 - 09:30
+1
Tue, 05/19/2009 - 14:27
Dear Roman,
I am a layman in licensing concepts. The Salome platform is also from OpenCascade SAS. Is the license of OCC & Salome are same? There is a detailed list of FAQ in Salome website http://www.salome-platform.org/faq/#_Toc165519938.
People may be interested in the below one.
1.2.3. If I developed a new Salome module can I sell it with Salome platform?
Yes, you can. However, you can charge the price only for your module, while SALOME itself is free.
You must give prominent notice with each copy of the distribution that Salome is used in it and that Salome and its use are covered by LGPL license.
Tue, 07/07/2009 - 09:43
Roman,
I'm here on behalf of the HeeksCAD project. Like many other opensource projects using OpenCascade, we have very little hope of being taken up by a main stream distribution because our dependencies (OpenCascade) will not be integrated into the main repository due to licensing issues. Imho, just removing the preamble text would make the license free. I will be contacting the free software foundation to verify this. Is there any hope of changing this or the releasing under a different license. I would be interested to know how feasible you think this is.
I am tempted to try and convince the fsf and/or distributions that many non-free packages, may be free enough. This sounds like an uphill battle to me. Is it an issue of lawyers hours and money? There is probably enough support out there to get donations for fixing this.
Thanks,
Jon Pry
Tue, 04/27/2010 - 04:05
Hi, has there been any progress on this at all? I feel like this is holding back the progress of Open CASCADE on Linux a lot. As a developer I'm not going to bother working on any projects that use Open CASCADE if my distribution won't include it in their repository. It seems like it should be fairly straight forward to get this sorted out. Either dual license under LGPL + OpenCASCADE or another license, license it under LGPL with some exceptions, or just work with the FSF or Fedora legal team to fix up the small problems with the OpenCASCADE license so that it's acceptable.
Thanks,
Adam
Tue, 08/28/2012 - 04:16
Bonjour,
J'ai publié une compilation de logiciels libres pour les entreprises sur http://compilibre.sourceforge.net/index_fr-FR.html
J'aurais aimé y joindre HeeksCAD et FreeCAD basés sur OpenCascade mais la licence d'OpenCascade m'est étrangère et je n'ai pas le temps ni les compétences pour l'analyser.
Pourriez-vous envisager le passage (ou une double licence) à une licence approuvée par la FSF ou l'OSI?
Il y a le choix : http://www.gnu.org/licenses/license-list.fr.html
Cordialement
Fri, 02/27/2009 - 15:52
I'd like to add another +1. I'm a scientist, not a software engineer (and certainly not legal). Changing to a well known FLOSS license would make it easier for me to use OCC without thinking about licensing. I'd like to release my software as GPL and know that all the dependencies are simple.
I also think changing the license to something well known (such as GPL) would allow/encourage major distros to include OCC as a standard package. We could then focus on using OCC and making some neat software. Filling the CAD gap in the open-source world is fantastic, but uptake has been slowed down by license confusion. I'd love to see this cleared up.
Fri, 02/27/2009 - 16:04
+1
A standard OS license is a huge deal and definitely will bring wider acceptance.
Tue, 03/03/2009 - 20:40
Hi together,
Im the maintainer of the FreeCAD project and we undergo also the painfull discussion with the distro maintainers about this license. Same result - considered as incompatible with GPL and there fore non-free.
Following this discussion and other opinions I strongly doubt that this license could survive in court. The longer I dig in this licensing issues (I dont whant, but I have to) IMO strongly doubt that home brew licenses like this one can survive.
Some *advantages* like static linking is not worth the pain of a unknown license.
There for I also ask the CasCade company to think of a compatible license. IMO the LGPL 2+ is appropriated. Otherwise we have to face the exclusion from all major distros. That would void all what you want to reach with open source OCC. Our applications distributed by distros and used by as much people as possible will draw attention and developers to OCC.
That was my +1
Jürgen
Mon, 03/16/2009 - 01:39
Let me chime in as the (lead) OCC package maintainer for Debian. I am very grateful that just last week Debian accepted my Debian Open CASCADE package (with much work from Denis Barbier who started this thread) into its main section, giving OCC a major distribution endorsement as free software.
But GPL compatibility is still a major issue for FreeCAD, because although FreeCAD changed its license to LGPL, it links with the Coin3D license which is GPL, and SIM has said they will not change their license to be OCC-compatible (not even a linking exception). So changing to LGPL would be a big help.
That said, I'm not sure I see why you don't think LGPL code can be statically linked. Numerous LGPL packages come with dynamic and static libraries, and nothing in the license prohibits static linking.
Thanks everyone for a great discussion!
Mon, 03/16/2009 - 17:20
Hi Adam, Roman and I discussed this LGPL issue wrt static linking on his blog.
Wed, 03/04/2009 - 23:31
This turned out into a fantastic thread, and recent comments from Tom, Jurgen and others added a terrific value. It has been vital to hear subject matter experts and Open Source representatives on the issue. Thank you!!!
I believe I am now convinced that LGPL 3.0 or 2.1 (+ explicit exception for not infecting user's code with templates, inlines, etc - as simple as Qt 4.5 just did for example*) will be the best choice. Static linking should not be a big deal, in my opinion, as presumably very small percentage of users is using it, and their reuse of dynamic linking will be just a small price for a great license simplification. By the way, adoption of LGPL will also be consistent with Salome which is LGPL-licensed.
So, let us hope the Open CASCADE development team will convince their management to adopt LGPL in some reasonable timeframe. Meanwhile I'd suggest that we keep on posting additional comments and examples why this would be beneficial.
Roman
opencascade.blogspot.com - the Open CASCADE blog
* here is what comes with Qt 4.5.0, now LGPL'ed:
Nokia Qt LGPL Exception version 1.0
As a special exception to the GNU Lesser General Public License
version 2.1, the object code form of a "work that uses the Library"
may incorporate material from a header file that is part of the
Library. You may distribute such object code under terms of your
choice, provided that the incorporated material (i) does not exceed
more than 5% of the total size of the Library; and (ii) is limited to
numerical parameters, data structure layouts, accessors, macros,
inline functions and templates.
Sun, 04/04/2010 - 21:31
Any update on the licensing?
Mon, 04/05/2010 - 09:22
I wish. I can't seem to find much of anything. Even Wikipedia links to this thread.
Wed, 04/08/2009 - 21:47
The "wxWindows License" might be worth looking at as a starting point. It is compatible with the (L)GPL and commercial applications, though it removes the restriction of having to distribute library source code changes:
http://www.opensource.org/licenses/wxwindows.php
Cheers,
Demian
Mon, 04/13/2009 - 21:27
Hi Demian,
Thanks for the link. Yes, wxWindows license (governing wxWidgets as most well known example) is known for this permissive exception. However this is not the intent for Open CASCADE. Modifications in the Open CASCADE must still be available under original license, currently OCCTPL or LGPL/whatever in the future. In this sense it is a copyleft.
Roman
---
opencascade.blogspot.com - the Open CASCADE blog
Tue, 04/14/2009 - 02:42
Ok, as far as I know, there are two licensing problems being discussed in this thread:
1) LGPL is "viral" and might force the user to release their code under the same license in some situations
2) License wording that should give their improvements back to OCC, and the fact that some feel that such a provision makes the software non-free.
The solution to #1 is to dual-license, under both the current license and LGPL. The LGPL won't bother people working on open source projects.
The solution to #2 is to change the wording of OCCTPL, such that the user will make a "reasonable effort" to give their modifications back to OCC. "Reasonable effort" would mean e-mailing a working, standard-format, patch file to OCC, along with a description of the change and (preferably) how to reproduce the undesired behavior. If OCC did not acknowledge receipt in 10 days, user tries again. Once the user has tried a second time, the obligation is satisfied.
As far as I know, the (L)GPL allows you to grant exceptions but does not allow for additional restrictions, so #2 solution probably can't be used with the LGPL. On the other hand, people who would choose to use OCC under the LGPL would have no reason to withhold their modifications from OCC, and simply asking to "please mail any bugfixes and improvements, in patch form, to blah@occ.org" would probably be effective.
Mark
Tue, 04/14/2009 - 18:19
If I add a nice feature to OCC and this is then included in OCC, how would this work with an LPGPL like license as OCC will then distribute the changes I have made to paying customers but non paying customers will not receive the code until a "major" release is made ? or is this a one way street only so I have to give my code to OCC but they don't have to return it to me ?
I understand that they can do what they want with their code, but my code is licensed under the LPGPL what ever you cant to call it license and how can they refuse to give that code to me ? or how can they mix my code with the original OCC code ?
Thu, 04/16/2009 - 23:58
Mikael,
That's why to enable effective contribution, a copyright waiver is required. When a contributor agrees to contribute he/she need to withdraw any claims and transfer copyright to the code owner. At first sight, this may sound dishonest but at the end of the day it is a better alternative for everyone than having a product of multiple copyrights contamination what would make the product totally unmanageable and would not help anyone. For almost 10 years when Open CASCADE is available in open source I have not seen any serious contribution that would be a noticeable feature (apart from port on autoconf/automake by Robert Boehne back in 2000). (Please correct me if I am wrong).
So when Open CASCADE becomes LGPL (one day, hopefully) anyone making any modifications will have to license those modifications under LGPL, should he/she will to integrate it into the source base he/she must be ready to disclaim copyright claims. Yes, Open CASCADE is free to use those modifications in its commercial projects, just like anyone else here, and to deliver them to its paying customers ahead of others. So what ? It's fair, it's open source, isn't it ? I don't see a problem here.
Roman
---
opencascade.blogspot.com - the Open CASCADE blog
www.cadexchanger.com - CAD Exchanger, your 3D data translator
Thu, 09/01/2011 - 20:13
OpenCASCADE still appears to be under a non-free license, incompatible with Fedora and others. I would like to get it going with HeeksCAD and FreeCAD. Both programs would have likely developed quite a bit more had OpenCASCADE been under a "normal" license these last couple years since this thread started. That would have allowed them to enter the repositories gaining new users and developers. OpenCASCADE would have benefited from this exposure as well. What's the point of the weird license you have? What is the objection to placing it under the LGPL so things can move forward?
Thanks,
-Jeff
Sun, 12/23/2012 - 05:37
Sadly, we all lost out today when we found that FreeCAD's new CAM workbench may not link to a very promising CAM library licensed GPLv3 because of incompatibility with OCTPL.
If OpenCASCADE were licensed under OCTPL or GPL, at the user's option, I believe that Roman's required protections for his company would be maintained and the company would benefit from the big distros carrying OpenCASCADE, free of controversy.
Please read in the FreeCAD CAM forum to get a sense of the frustration felt by those involved with the project.
John Morris
co-maintainer of FreeCAD packages for RPMFusion