chitubox sdk for citubox 1.9 version

[bvin1973]

Hi all
CHitubox is ready to offer sdk for repairing ctb file which is encrypted in version 1.9 of chitubox

please fine their reply to the above query.

"We haven't received any SDK requests from the UVTools team yet. We're willing to provide the SDK, but making UVTools implement our SDK, this job can't be done from our side.

If they're don't have the willingness to implement the SDK or if this is not their priority currently, we can't force them to.

Maybe you can try to contact their team and ask their opinion about this.
We look forward to receiving their SDK request. "

developer team please see if you can connect with Chitubox team to request the sdk and get the needful done.
regards
bhavin

[tslater2006]

The SDKs licensing terms are hostile at best. Both for users and software authors. I'll let @sn4k3 speak for himself, but I do not see a future in which UVTools can implement the SDK and follow the licensing terms. This request is basically dead on arrival.

[sn4k3]

Funny... Thier "SDK" license is not compatible with open-source, they know that and they make it in that way to make sure no one use it.
They are just getting away and tell users that the problem is the others that dont want to incorporate thier SDK. In the end i'm the bad guy here...
To know more read: https://www.chitubox.com/en/article/law/ctb-sdk/agreement_for_non-profit_entity

It's dead on many points, but read this:

14.自由和开源组件Free and Open Source Components

Notwithstanding any provisions to the contrary in this License Agreement, the use, copying and distribution of the SDK components licensed under the free and open source license agreement are only subject to the terms of these free and open source license agreements, and the terms of this License Agreement shall not apply to such components. The relevant free and open source license agreements are contained in the electronic files attached to the SDK. Regarding such open source software licenses and all rights granted, you agree to maintain a good reputation as a Licensee and avoid any possible termination, suspension or infringement of such rights.

You are not licensed (and you agree that you will not) combine this SDK with any viral open source licensed software or use it in conjunction with such software, or take any other forms that may be required to disclose, distribute or license this SDK or The behavior of all or any part of the API. For the purpose of these terms, "viral open source license" refers to the license granted based on the "GNU General Public License", "GNU Reduced General Public License" or any other similar license, This type of license requires you to use, modify or distribute such software without charging fees, or you must disclose, distribute or license the software in the form of open source code. If you have any violation of the foregoing terms, under this license Agreement The license and other rights granted to you regarding this SDK will be terminated immediately.

(and you agree that you will not) combine this SDK with any viral open source licensed software or use it in conjunction with such software ... "viral open source license" refers to the license granted based on the "GNU General Public License", "GNU Reduced General Public License" or any other similar license

This kills any open-source software from using this. And BTW this is not an SDK, is an developer NDA.
Also you must know that UVtools is truly open-source, all dependencies must be too. A closed-source dependency in the project will kill the open-source nature of the project.
A Chitubox guy contact me before the SDK release, and i told them that, i think they don't understand the concept of OpenSource, worse, they are against it as you can see on the license.

Even if they come with a "dedicated special" agreement i will not accept it.
I'm against this kind of policies and restrictions. They are grounding mSLA technology and restricting users, if you keep your head down and accept everything, things will move very slow and in thier benefit and at the user cost.

As bottom line: UVtools already supports and have the format working long time ago by our raw implementation, it's enabled as read-only, and that is already more than i wanted initially... In other words, we don't need SDK to have the format working. So it's useless to have it anyway.

[tslater2006]

I didn't realize they actually forbid you from using it in GPL'd code. That's wild.

[sn4k3]

In fact they forbid all use... Read that:

"...or take any other forms that may be required to disclose, distribute or license this SDK or The behavior of all or any part of the API..."

If you can't distribute the SDK or use any part of the API how you gona use it and distribute your software?

The license itself is messy, unclear and bad written with contradictions

[oelmekki]

Seriously, Chitu is the archvilain of the industry… This level of condescendence on their part reminds me of Microsoft in the early 2000. I bet that a decade from now, they'll have lose as much market share and will claim everywhere as well that they changed and now love opensource… In any case, they make me think that we may need to reboot the RepRap project. I'm only starting to dig into electronics myself (from a developer background), but I know what will be my first target.

In the mean time, do you have any recommandation on what printers to use instead of the Chitu based ones, in the same hobbyist price range? With uv3dp not maintained anymore, UVtools has become the only champion of FOSS in the SLA world (that is, with Prusa, which I love and would love to buy from, but their hardware is too expensive for me). Maybe it would make sense to add such recommendations in the README?

[sn4k3]

Yes we need to get over this BS and start to open stuff and able to revive old machines and improve thier capabilities. We are producing a ton of trash as thier strategy is kill the product once release and make a new one...

One Firmware alternative is start to pop: https://github.com/nviennot/turbo-resin not chitu but is a awesome progress to unlock a brand!

any recommandation on what printers to use instead

For me i stay away of everything that restrict me, that being said is almost every printer except the gcoded ones.
Problem is, gcode printers are just a few on the market and they tend to have some flaws. Still with gcode you have "full" control over printer movements.
Because of that i went to Uniz IBEE printer, which is linux+gcoded, it is built like a tank, very good light source, i print with 2mm lift height @ 150mm/min and 100um with great details (See last picture). But nothing is perfect... that machine firmware is a bit tricky and have stupid bugs that they refuse to fix (they no longer do updates) which is a shame! When you know the bugs you know how to avoid them and that won't be a problem. They had a killer machine and they could have the "best" consumer printer if they aren't so stupid and closed eyes. They also refused to private share the firmware in order for us to improve it at no cost...
I still recommend the printer because of the amazing build quality and robust printer, it could be a gold mine for them but you know...
Beside IBEE you have Nova printers which are gcode too, but old models are buggy and not soo good, i dont know about the new models.
Other note about ibee: It looks the spare parts are hard/expensive to get, anyway you just need the LCD as other stuff will survive. Plus it is HDMI driven, so you can put any board that support hdmi connection (Some will pop off as opensource)

Peel: https://youtu.be/fkfIMyo0_aI (Slow down to 0.5x)

[oelmekki]

One Firmware alternative is start to pop: https://github.com/nviennot/turbo-resin not chitu but is a awesome progress to unlock a brand!

Oh wow, that's awesome, thanks for sharing. I see they're after hardware owners to find specs and probably try the firmware, I have a Saturn and a Mars 2, with the Mars 2 basically not used anymore (so I can go wild with it), I'll see if I can help.

And indeed, we probably don't need RepRap-style "building from scratch", with the amount of commercial hardware we now have : we "just" need to retrofit them with open firmwares.

Still with gcode you have "full" control over printer movements

I assume they're still using pictures of layers? The gcode is for the lift off distance / wait on bottom / lift speed instructions, maybe?

Because of that i went to Uniz IBEE printer

Thanks, it looks great. Somehow, that's the first time I ever heard of Uniz, I guess that's because they're more expensive than the Elegoo/Phrozen/Anycubic printers, and thus less talked about.

Coming from FDM printing (and only running FOSS on my laptop, except for the BIOS), finding a FOSS-friendly printer was an important thing for me when I looked at it first. And I almost gave up on resin printers, until finding about uv3dp and UVtools, which I could use to convert files from prusa-slicer. I would think that many people discover UVtools the same way, looking for FOSS resin software, so having a note in README or a wiki page mentioning that printer would probably be of interest for them. That would also be a good opportunity for having people report other FOSS-friendly printers we may not know.

[sn4k3]

I assume they're still using pictures of layers? The gcode is for the lift off distance / wait on bottom / lift speed instructions, maybe?

Yes, png files into a zip which solve some limitations of RLE on other formats.
Gcode is the instructions yes, and with that you can instruct to do whatever you want (inside the command universe), there's no strict manifest to follow to lock you out.

FOSS-friendly printer

I dont know if there is any... Even Prusa i think its not 100% open-source?
Prusa machines are good in hardware, but stock firmware is much more limited than a chitu printer, as you can't have per layer settings.
FDM is miles ahead of mSLA.

[oelmekki]

I dont know if there is any... Even Prusa i think its not 100% open-source?

Oh yeah? Their firmware looked clean to me, but I didn't do an advanced audit. With the amount of submodules and fetching, I guess a binary blob may be hiding somewhere. Well, at least, it's not Anycubic-level of "it's opensource because we have 'a github'!". ^^

you can't have per layer settings

I've seen that feature in ctb files, but I don't understand the point. When do you need it, beside the bottom layers exposure time and lift speed?

FDM is miles ahead of mSLA

Yeah indeed, there's a strong case for open firmware, if anything because it'll allow for fork and adding the features we want.

[X3msnake]

afik prusa sl1 is fully opensource, in hardware software and fw No dia sexta-feira, 11 de fevereiro de 2022, Tiago Conceição < ***@***.***> escreveu:

…

I assume they're still using pictures of layers? The gcode is for the lift off distance / wait on bottom / lift speed instructions, maybe? Yes, png files into a zip which solve some limitations of RLE on other formats. Gcode is the instructions yes, and with that you can instruct to do whatever you want (inside the command universe), there's no strict manifest to follow to lock you out. FOSS-friendly printer I dont know if there is any... Even Prusa i think its not 100% open-source? Prusa machines are good in hardware, but stock firmware is much more limited than a chitu printer, as you can't have per layer settings. FDM is miles ahead of mSLA. — Reply to this email directly, view it on GitHub <#319 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUR56XCAVRQGL23VJXZRR3U2SHGJANCNFSM5F2LVJ6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Com os melhores cumprimentos, Vinicius Silva

[X3msnake]

per layer settings allows you to have variable layer height for faster and better quality prints. it also allows you to print simultâneos tests at different exposures for example. it is a must. No dia sexta-feira, 11 de fevereiro de 2022, kik ***@***.***> escreveu:

…

I dont know if there is any... Even Prusa i think its not 100% open-source? Oh yeah? Their firmware <https://github.com/prusa3d/Prusa-Firmware-SL1> looked clean to me, but I didn't do an advanced audit. With the amount of submodules and fetching, I guess a binary blob may be hiding somewhere. Well, at least, it's not Anycubic-level of "it's opensource because we have 'a github'!" <https://github.com/ANYCUBIC-3D/PhotonWorkshop/tree/master/Tools>. ^^ you can't have per layer settings I've seen that feature in ctb files, but I don't understand the point. When do you need it, beside the bottom layers exposure time and lift speed? FDM is miles ahead of mSLA Yeah indeed, there's a strong case for open firmware, if anything because it'll allow for fork and adding the features we want. — Reply to this email directly, view it on GitHub <#319 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUR56VEBUG7SR4AHUAII3LU2TT4HANCNFSM5F2LVJ6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

-- Com os melhores cumprimentos, Vinicius Silva

[oelmekki]

I see, thanks for pointing it out.