I don't see that the author has clearly copied anything there. Maybe he did, maybe he didn't. This situation only proves open-source licensing is in a bad shape.
Actually it is horrible. See, for example, the criticisms and questions being raised on the whole thread about this library.
(Until anyone point a better alternative, I'm for "if you don't want anyone using them, don't publish your sources".)
> But once you have done modifications to Yue's source code, all your code linked with Yue have to be open sourced with MS-RL. The only way to remove this limitation is to subscribe to Yue's paid plan.
> The license seems like a non starter.
> Note that the license of Yue has less restrictions than LGPL, it does not require you to open source your project when you statically link with Yue, or compile Yue's source code as part of your project.
> So if you are fine with LGPL libraries, there is no reason to worry about Yue's license.
> Yue is just another open source project with dual licenses, and it has less restrictions than most dual licenses projects.
With the LGPL you can change the code, compile and dynamically link without releasing your own code. It's a significant difference.
With Yue's license you can change the code, compile and dynamically link without releasing your own code.
There is no difference here.
Lest you doubt:
Reciprocal Grants- For any file you distribute that contains code from the
software (in source code or binary format), you must provide recipients the
source code to that file along with a copy of this license, which license will
govern that file. You may license other files that are entirely your own work
and do not contain code from the software under any terms you choose.
Hi everyone, I have written a C++ library for creating native GUI apps, it also has language bindings for Lua and JavaScript (V8).
In the past I have written the Electron framework, which is a popular project for creating desktop apps with Chrome web engine and Node.js, while this library allows you to create native desktop apps.
> In the past I have written the Electron framework, which is a popular project for creating desktop apps with Chrome web engine and Node.js, while this library allows you to create native desktop apps.
Are you the same developer Roger Wang wrote about in his "Statement on the history of node-webkit project" public post?
He claims you misrepresented the scope of your work as an intern on the node-webkit project (now named nw.js), and that you removed copyright notices from code in Electron that was derived from node-webkit.
" Furthermore, the Intel copyright notices were removed and were replaced by GitHub copyright notice in Electron when pieces of code was copied and derivative work was made from some code of node-webkit " ....
" I wouldn't like to spend time on this, but as the previous co-maintainer of node-webkit project, keeps spreading misinformation about his internship work in the node-webkit project on his blog post" ...
>If you are wondering how this library is different from other GUI toolkits, check out the FAQ
I see no details at all about how this library is different [or not]. While not an UI expert, I have some low-level experience with gtk, qt, appkit and uikit, vcl, immediate ui, and full manual drawing / event processing. When considering new ui framework, these questions are of high priority: how does it integrate with, or supports for, existing custom run loop; what layout system is used and which problems it elegantly solves (i18n, baselining, excessive boxing, complex constraint cases); how does it implement repeating cell rendering and caching, if any; what are base classes and how metamechanics like scrolling/resize/animation/state cues are distributed across these; how does ui state interact with controlling entity and vice versa; which non-ui mid-controllers exist to reduce or abstract out basic boilerplating. Without these details, it is yet another "throw edits, buttons and labels to fixed form and call it a day framework" at most. UI is usually hard because of internals and extension, not because it lacks fixed functionality. Web is partly so popular because it feels like everything is possible from the styled box primitive (but has its obvious downsides; like a 100mb complex c++ rendering engine that only few groups in the world can implement correctly and somewhat effectively on latest i7). Without all this and many more, there is nothing to reason about — ui is not a yesterday's demand, and regular cases are covered by virtually any mature library. Drawing static hearts with beziers is not a big deal.
Tbh, I'm highly doubting any of listed topics can be designed in just one version step, because even most decent frameworks have so many hidden flaws that require insane efforts to overcome under specific requirements.
It would be great to see how it is actually better, e.g. by comparing side-by-side examples of solving normal-to-hard ui tasks in different libraries.
I'm sure this is an amazing project. But the readme and FAQ and such have such an aggressive, almost hostile tone---if you want to communicate with the author at all, even to report a bug, it'll be five thousand bucks a month...
The author literally says: "for help please go to the yue/help repo where users help themselves.
To report a bug, you have to create a pull request with a test case of your problem, or you can choose to subscribe to paid plans."
What's exactly hostile there?
The author gave you, the potential user, a gift, totally free of charge, and even explained politely where and how to find help. They even organized a premium support, if someone's problem is so important that it needs extra care.
I don't get that either.
Also look at https://github.com/yue/help. The author is basically saying "I'm a really cool developer, was there, did that, anything else?". Every single sentence consists of narcissism (or how should I call that?). This is only how I see that, I'm sorry if I offended somebody.
Unfortunately, this library has no support for accessibility, e.g. for blind users with screen readers, particularly on Windows, where it implements its own windowless controls without implementing the UI Automation API. So I advise against using this library for any application with a broad target user base until this problem is addressed.
With a quick glance, I learnt about the intrincate details of the license. However, I have no idea of the technical details behind the library or how the relevant code may look like (note that I can go to the sample sources, but without a proper introduction it takes some work to follow).
I'd suggest putting more emphasis in the library details, and why it is good (not just how good it is) especially before all that licensing information.
It'd be really helpful if there were screenshots of a sample app from each supported platform. Is this wrapping native elements or providing custom elements?
If I'm understanding you correctly, what you've asked for is already there. Follow the "Sample Apps" link to here https://github.com/yue/yue-sample-apps and then click on one of the sample app directories and there are screenshots.
Is there any open source project where the author retains copyright?
I mean in this case I'd say the copyright is transferred to a nameless entity, e.g. "the Yue project". IIRC any project with a developer agreement (like Google's) include a transferrence of copyright note.
Nifty! I look forward to (hopefully/eventually) someone making Go bindings for this :)
With that said, it would be nice if the sample apps included more components of the native UI. Eg, a bunch of buttons, text editors, etc - a sort of kitchen sink screenshot. Just to understand what it looks like on each OS. All the samples I saw so far seemed very limited, visually.
Im very confused what is going on here. He works for electron full time but is releasing something else thats basically the same with more confusing terms?
As far as I understood Yue is a GUI toolkit that wraps the platforms' native widgets, whereas Electron is a Node runtime and a Chromium instance (which lets you build GUIs with web technology).
Right, So I am doing a research project and If I want to use this library in that project, does that mean I have to pay to use it. My project is currently closed source , because don't want anyone to steal stuff before I publish my paper. After that the code goes public.
[+] [-] Jasper_|8 years ago|reply
You're using large parts of WebKit source code (LGPL) in your proprietary library. This is against the license. Please compare:
https://github.com/yue/yue/blob/master/nativeui/gfx/gtk/pain...
https://github.com/WebKit/webkit/blob/master/Source/WebCore/...
[+] [-] aaron-lebo|8 years ago|reply
https://news.ycombinator.com/item?id=15219048
[+] [-] drinchev|8 years ago|reply
Created an issue for this to prevent anyone else using it.
Let's see how the author will respond.
https://github.com/yue/help/issues/4
[+] [-] Doctor_Fegg|8 years ago|reply
[+] [-] smegel|8 years ago|reply
What makes it proprietary?
[+] [-] fiatjaf|8 years ago|reply
Actually it is horrible. See, for example, the criticisms and questions being raised on the whole thread about this library.
(Until anyone point a better alternative, I'm for "if you don't want anyone using them, don't publish your sources".)
[+] [-] irq-1|8 years ago|reply
> But once you have done modifications to Yue's source code, all your code linked with Yue have to be open sourced with MS-RL. The only way to remove this limitation is to subscribe to Yue's paid plan.
> The license seems like a non starter.
> Note that the license of Yue has less restrictions than LGPL, it does not require you to open source your project when you statically link with Yue, or compile Yue's source code as part of your project.
> So if you are fine with LGPL libraries, there is no reason to worry about Yue's license.
> Yue is just another open source project with dual licenses, and it has less restrictions than most dual licenses projects.
With the LGPL you can change the code, compile and dynamically link without releasing your own code. It's a significant difference.
[+] [-] ww520|8 years ago|reply
[+] [-] rhencke|8 years ago|reply
There is no difference here.
Lest you doubt:
[+] [-] zcbenz|8 years ago|reply
In the past I have written the Electron framework, which is a popular project for creating desktop apps with Chrome web engine and Node.js, while this library allows you to create native desktop apps.
If you want to see some screenshots and example code, check out the sample apps repo: https://github.com/yue/yue-sample-apps.
If you are wondering how this library is different from other GUI toolkits, check out the FAQ: https://github.com/yue/help#faq.
If you want to learn this library quickly, there is a detailed tutorial on using Yue with Node.js: http://libyue.com/docs/v0.2.0/js/guides/getting_started.html.
[+] [-] jancsika|8 years ago|reply
Are you the same developer Roger Wang wrote about in his "Statement on the history of node-webkit project" public post?
https://groups.google.com/forum/#!topic/nwjs-general/LIrC7zH...
He claims you misrepresented the scope of your work as an intern on the node-webkit project (now named nw.js), and that you removed copyright notices from code in Electron that was derived from node-webkit.
[+] [-] 0x1Null|8 years ago|reply
" I wouldn't like to spend time on this, but as the previous co-maintainer of node-webkit project, keeps spreading misinformation about his internship work in the node-webkit project on his blog post" ...
Why are you misrepresenting your work..
[+] [-] zerr|8 years ago|reply
> Uses windowless controls on Windows;
Don't these contradict each other? What do you mean under "windowless" and why it is important?
Btw, you can list particular advantages/comparison at least over top 3 popular C++ cross-platform UI toolkits: Qt, wxWidgets, Gtk+/Gtkmm.
[+] [-] wruza|8 years ago|reply
I see no details at all about how this library is different [or not]. While not an UI expert, I have some low-level experience with gtk, qt, appkit and uikit, vcl, immediate ui, and full manual drawing / event processing. When considering new ui framework, these questions are of high priority: how does it integrate with, or supports for, existing custom run loop; what layout system is used and which problems it elegantly solves (i18n, baselining, excessive boxing, complex constraint cases); how does it implement repeating cell rendering and caching, if any; what are base classes and how metamechanics like scrolling/resize/animation/state cues are distributed across these; how does ui state interact with controlling entity and vice versa; which non-ui mid-controllers exist to reduce or abstract out basic boilerplating. Without these details, it is yet another "throw edits, buttons and labels to fixed form and call it a day framework" at most. UI is usually hard because of internals and extension, not because it lacks fixed functionality. Web is partly so popular because it feels like everything is possible from the styled box primitive (but has its obvious downsides; like a 100mb complex c++ rendering engine that only few groups in the world can implement correctly and somewhat effectively on latest i7). Without all this and many more, there is nothing to reason about — ui is not a yesterday's demand, and regular cases are covered by virtually any mature library. Drawing static hearts with beziers is not a big deal.
Tbh, I'm highly doubting any of listed topics can be designed in just one version step, because even most decent frameworks have so many hidden flaws that require insane efforts to overcome under specific requirements.
It would be great to see how it is actually better, e.g. by comparing side-by-side examples of solving normal-to-hard ui tasks in different libraries.
[+] [-] Vinnl|8 years ago|reply
[+] [-] paultopia|8 years ago|reply
[+] [-] dragandj|8 years ago|reply
The author literally says: "for help please go to the yue/help repo where users help themselves.
To report a bug, you have to create a pull request with a test case of your problem, or you can choose to subscribe to paid plans."
What's exactly hostile there?
The author gave you, the potential user, a gift, totally free of charge, and even explained politely where and how to find help. They even organized a premium support, if someone's problem is so important that it needs extra care.
I'm still puzzled...
[+] [-] bitcoinofficial|8 years ago|reply
[+] [-] zcbenz|8 years ago|reply
And as explained in the FAQ, you can always go to the yue/help repo to report things and I will read them.
[+] [-] imron|8 years ago|reply
That's not quite true - the other option is to provide a pull request with a test case showing the bug.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] mwcampbell|8 years ago|reply
[+] [-] setzer22|8 years ago|reply
I'd suggest putting more emphasis in the library details, and why it is good (not just how good it is) especially before all that licensing information.
[+] [-] pbnjay|8 years ago|reply
[+] [-] joemi|8 years ago|reply
[+] [-] drinchev|8 years ago|reply
Nevertheless I'm still afraid that features / maintenance will be unsustainable, since you are the only developer [1] ( considering your expertise ).
I hope there are companies that support the project.
1: https://github.com/yue/yue/graphs/contributors
[+] [-] Zekio|8 years ago|reply
https://github.com/yue/yue/tree/master/docs/paid_plans
[+] [-] dragandj|8 years ago|reply
I'm not even a potential user of this library. I'm just amused with how people expect open source programmers to work for peanuts.
[+] [-] carussell|8 years ago|reply
[+] [-] imron|8 years ago|reply
[+] [-] jbergstroem|8 years ago|reply
[+] [-] fluxsauce|8 years ago|reply
Nope.
[+] [-] Cthulhu_|8 years ago|reply
I mean in this case I'd say the copyright is transferred to a nameless entity, e.g. "the Yue project". IIRC any project with a developer agreement (like Google's) include a transferrence of copyright note.
[+] [-] notheguyouthink|8 years ago|reply
With that said, it would be nice if the sample apps included more components of the native UI. Eg, a bunch of buttons, text editors, etc - a sort of kitchen sink screenshot. Just to understand what it looks like on each OS. All the samples I saw so far seemed very limited, visually.
[+] [-] ComodoHacker|8 years ago|reply
0. https://sciter.com/
[+] [-] c-smile|8 years ago|reply
With modern high-DPI monitors, when number of pixels is 4...9 times larger than on old 96ppi monitors, non-GPU rendering is not an option anymore.
[+] [-] nautilus12|8 years ago|reply
[+] [-] eivarv|8 years ago|reply
As far as I understood Yue is a GUI toolkit that wraps the platforms' native widgets, whereas Electron is a Node runtime and a Chromium instance (which lets you build GUIs with web technology).
[+] [-] harisvs-code|8 years ago|reply
Its a WIP
[+] [-] viach|8 years ago|reply
[+] [-] eivarv|8 years ago|reply
Maybe now we'll finally see accessible and efficient GUI apps from those who insist on writing desktop applications with JS.
[+] [-] majewsky|8 years ago|reply
Too bad it ignores accessibility entirely: https://news.ycombinator.com/item?id=15219025
[+] [-] wheresvic1|8 years ago|reply
[+] [-] z3t4|8 years ago|reply
[+] [-] eivarv|8 years ago|reply
[+] [-] _binder|8 years ago|reply
[+] [-] iainmerrick|8 years ago|reply
As long as you don't make any changes, sounds like it's free and unrestricted.
[+] [-] fiatjaf|8 years ago|reply
[+] [-] brodock|8 years ago|reply