Switch to LibreDWG #207
Comments
|
LibreDWG's support has been very spotty, how is your fork ( is it a fork??) going to change this? |
|
You missed to copy this from http://git.savannah.gnu.org/cgit/libredwg.git/tree/NEWS:
After years of silence LibreDWG has got some attention for half a year now and its releases are marked as still alpha. |
|
Yes, but compare the code with yours - at least it is active and has more
features.
…On Fri, Jan 4, 2019, 8:01 AM Armin Stebich ***@***.*** wrote:
You missed to copy this from
http://git.savannah.gnu.org/cgit/libredwg.git/tree/NEWS:
LibreDWG version 0.7 - released 2018/12/6 - *still alpha*:
After years of silence LibreDWG has got some attention for half a year now
and its releases are marked as *still alpha*.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#207 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMZ_WXyGSxCIGYEw_LqPs25JlSMdDyLks5u_pnZgaJpZM4Zn6ty>
.
|
|
@rvt it is not my fork, it is a mainline. |
|
The point in alpha state code is:
So it's just the wrong time now to decide about this step. |
Propose reactivate this discussion, as there are many changes since LibreDWG Changes since *LibreDWG* `v0.7` |
|
We need to think if GPLv3 is compatible with out licence model if we want to use it. |
As I understand, LibreDWG is under And LibreCAD So, there are NO any issues. |
|
Ok, somebody overwrite the licence to be GPLv3, there was never permission to do so : See original https://github.com/LibreCAD/LibreCAD_3/blob/645ac3d971a8c3727de206e16ed110cff6245dfe/LICENSE I will discuss this because it's been so long ago already, but we never noticed |
|
Isn't this just makes all new code (that was written after that change) to be under the GPLv3+? Since everyone who contributed after it thought the license is GPLv3? |
|
@XVilka yeaaa, that's a big issue indeed. GPLv3 limites the usage of the source code a lot, and that was never the intention. |
|
@gaganjyot thoughts? |
|
hope can change to libreDWG |
|
hope can change to libreDWG,too |
|
This message is regarding licensing. Regarding usage of LibreDWG, Please read my next message I investigated a lot on this during initial work and there are couple of things I'd like to mention: And before anything else, I'd like to mention I am not a license expert/Lawyer but I've did from my understanding of licenses. If you read the License Document it states https://github.com/LibreCAD/LibreCAD_3/blob/master/LICENSE
The current license of the LibreCAD_3 was made to GPL, but if you see, we just ship the application under GPL. That doesn't imply that the whole code needs to be GPL. If you see the librecad Kernel has BSD3 license https://github.com/LibreCAD/LibreCAD_3/blob/master/lckernel/LICENSE And this was supposed to be done for all the code that we have written as a part of LibreCAD_3, we might have missed to add that but at that time everything was a part of LCKernel and hence there was a miss. We currently depend on multiple Libraries that might have a GPL license, Cairo, Qt, Libdxfrw ( Rallaz ) or even if we think of LibreDWG. The plan and idea was that completely whole of code written in LibreCAD_3 ( except the main.cpp file ) can be MIT/BSD-3 license. Since we are dependent on GPL libraries, we could just make the main file as GPL license and ship the whole distributable as GPL. But the modules ( everything can be a shared library that links to main.cpp ) like LCKernel, LCViewer and all others will be MIT/BSD-3 The reason we are using GPL now is that we don't have all the libraries that are under MIT/BSD ( like UI, DXF/DWG read/write etc. ) But the whole code is BSD-3 so it doesn't limit the usage of sourcecode at all. If in future we could replace all the libraries with BSD-3/MIT license based ones, If everybody is okay, we can replace the GPL 3 Main file with a MIT/BSD based license and relicense the whole librecad. I hope I made things clear. Please let me know if there are any other questions. In other words: In all the cases the whole librecad_3 source code written by us is BSD-3/MIT If we are using any of the GPL libraries like dxf/dwg or even cairo/Qt we ship the software under GPL If we are not using any of the GPL libraries we can proceed further and ship the software under MIT/BSD-3 I feel this approach of licensing is very much flexible. But still, Please let me know if there are concerns. The code is completely under MIT/BSD-3 and lesser limiting in terms of usage. |
|
This message is regarding usage of LibreDWG. Regarding Licensing, Please read my previous message Glad that people are looking towards usage of LibreDWG, but before we just go further an use LibreDWG: I think many of us need to understand that if a library is not active that always doesn't means that it was abandoned or is bad to be used. Sometimes that could also mean that the reason the author developed the library is served for the author. Sometimes it could also mean that it is stable enough with respect to scope of development and not much can be added into it. For an example, Netflix's hystrix has mentioned this in their readme https://github.com/Netflix/Hystrix/blob/master/README.md Hystrix is no longer in active development, and is currently in maintenance mode. Hystrix (at version 1.5.18) is stable enough to meet the needs of Netflix for our existing applications. Meanwhile, our focus has shifted towards more adaptive implementations that react to an application’s real time performance rather than pre-configured settings (for example, through adaptive concurrency limits). For the cases where something like Hystrix makes sense, we intend to continue using Hystrix for existing applications, and to leverage open and active projects like resilience4j for new internal projects. We are beginning to recommend others do the same. Now if you feel that you need such a library, and if you don't use hystrix just because its in maintainence mode, to me it doesn't seem a real good decession. Now coming back to usage of LibreDWG in librecad, We need to see what are the advantages we are getting by using libreDWG instead of LibDXFrw, if the pros of libreDWG outweigh we can definitely look at it. Personally I think for what we have developed in LibreCAD_3 yet, we can stick to LibDXFrw for the moment until we face enough issues.
And my final 2 cents,
|
|
As an end user, in fact,i am not care on which lib is better. I just want LibreCAD2 can read and write DWG file. If someone can fix the problem on LibreCAD2 , it will be better. |
Why? Freely available specialised applications do it very poorly so why should LibreCAD attempt it? It will only lead to more disappointment. I my view dwg should be stripped out of LibreCAD and supported through plugins. It should be clear people can use plugins but they are not LibreCAD. Plugin support would rest with the plugin developer. |
|
Seems active enough (also now - beta): http://git.savannah.gnu.org/cgit/libredwg.git/tree/NEWS |
|
@flywire the same reason nobody would have used LibreOffice or OpenOffice without MSO formats support. |
|
@XVilka that is a good example but the issue is you are comparing a largely documented XML format with a largely undocumented DWG format. |
To be honest, "DWG not fully documented yet, but in progress". |
|
LibreDWG maintainer here. It is still beta, because there is still no proper CAD application usage, which I would need to fix any missing or bad API's. The gold standard are the existing VBA and partially AutoLISP API's, but there are several issues with them. Recently a new and extremely simple CAD program showed up which wants to use an API similar to AutoCAD's VBA. This is a good test case to write a proper but simple enough API to write DWG's. I wrote the DXF importer which was a good testcase, but it's way too much code. The new JSON importer uses a much simpler and more generic way to write DWG's. This still needs to abstracted into a good enough API. The above mentioned dynapi is done, and was used for the DXF and JSON importer. Very successfully. The python and perl bindings don't use it yet, the inwork gambas bindings (VBA alike) will use it. All future bindings will use it. Re licensing: There will be no changes. First the project is owned and defended by the FSF. You have to remember that we are dealing with one of the worst litigious companies here, right after Oracle. They sued OpenDWG for the use of trademarked names in the code, which was needed to be able to write to this format, so that programs could read that format. Only the FSF and the GPLv3 are strong enough to withstand such existential threats. |
|
There continues to be progress on LibreDWG ( https://savannah.gnu.org/news/?group=libredwg ) and LibreDWG is now supported OOTB (for 2D) in FreeCAD 0.19_pre ( https://wiki.freecadweb.org/FreeCAD_and_DWG_Import ) Would it be valuable to have a plugin to allow switching to and testing LibreDWG? If this was made as a plugin would it also work for LibreCAD2? Remember that LibreDWG also does conversion to SVG and DXF export. So it could provide new and/or improved functions. What would this take to get done? I we can start robust testing of LibreDWG for 2D CAD this would be great and push an active project forward faster. Over at osarch we are discussing promoting DWG work to the FSF for inclusion again on their High Priority Projects list. https://community.osarch.org/discussion/385/fsf-help-us-set-high-priorities-for-2021-send-input-by-jan-8 feel free to comment there on the general topic of DWG in FOSS. Opinions on support for DWG differ, but an issue tracker may not be the place for that discussion. |
|
related to LibreCAD/LibreCAD#1239 'Support for DWG format' in LibreCAD2 |
|
I am not sure if this is correct place to write my experience. Now Application->Graphics->ODAFileConverter worked |
@nishishailesh, are you tried to open DWG in SolveSpace? If so, you should provide SolveSpace version info and, if possible, such DWG file for test. |
|
@nishishailesh thanks for reporting the problem you're having. This is not the right place to add this issue since we're discussing pro/con for a switch to LibreDWG. Please create a new bug report and as @Symbian9 (hi there) suggests see if it opens in SolveSpace |
|
LibreDWG have support for readind dwg R2018 files (but it only write at R2000) and it is being actively developed. It would be nice to add a new branch for testing purposes. Time will tell which library (libdxfrw or LibreDWG) LibreCAD should focus |
|
Agree, latest release as of now is 0.12.5 with many changes. They also seem to fuzz the implementation as well: |
New version of LibreDWG library was released approximately month ago with a few good features
https://github.com/LibreDWG/libredwg/releases/tag/0.7
Your own library didn't update for years, feature difference is huge: https://github.com/LibreCAD/LibreCAD/tree/master/libraries/libdxfrw/src
It would be very beneficial to switch to this library finally.
new API:
analog to dwg_get_ENTITY, but including all objects, tables,
block headers, even if unowned.
Note that the dwg_api will be revamped from static to dynamic before 1.0.
field accessors will be by name argument and ... (va_args)
See the work/dynapi branch Replaced own solvers with Eigen polynomial solvers #59 (in progress).
dwg_get_OBJECT(dwg) will be renamed to dwg_getall_OBJECT(dwg),
dwg_get_ENTITY(blkhdr) to dwg_getall_ENTITY(blkhdr).
API breaking changes:
rename unknown_bit_4 to hookline_on,
endptproj only until r2007. (but still not 100% correct)
change vertex to points[] (PR Image fole formats support #49 Denis Pryt)
Important bugfixes:
For decode and encode.
(esp. for <=R12), and fix overflows (Gauss Jordan to Eigen colPivHouseHolderQr for Linear System Solver #56)
Other newsworthy changes:
if previously skipped.
"Out of memory"
The text was updated successfully, but these errors were encountered: