Show HN: Yue – A new library to create cross-platform GUI apps(github.com)
github.com
Show HN: Yue – A new library to create cross-platform GUI apps
https://github.com/yue/yue
105 comments
Is this guy just a bad citizen of the dev community?
https://news.ycombinator.com/item?id=15219048
https://news.ycombinator.com/item?id=15219048
Wow, that's very bad.
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
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
That's LGPL, not GPL.
Oops, I misread the license header. Fixed. You still can't relicense LGPL as MS-PL, though.
> You're using large parts of WebKit source code (LGPL) in your proprietary library. This is against the license.
What makes it proprietary?
What makes it proprietary?
For some reason I thought MS-RL wasn't an OSI-approved license, but it appears it is: https://opensource.org/licenses/alphabetical
Bad choice of words on my part, and I can't correct my comment anymore. That said, LGPL works still aren't compatible with MS-RL, so you can't distribute the combined work as MS-RL.
Bad choice of words on my part, and I can't correct my comment anymore. That said, LGPL works still aren't compatible with MS-RL, so you can't distribute the combined work as MS-RL.
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".)
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".)
The comments, flow control and variable names are the exact same, and the comments at the top of the file have the same emails as the WebKit source code. If that's not a clear cut sign of plagarism, I don't know what is.
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.
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.
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.
> 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?
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.
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.
Definitely, and those same claims are made in the yue docs.
>I had been the solo developer of Electron and node-webkit (now known as NW.js) for a very long time, and today big corps are building their new apps on them. So I think it should not be hard to be confident about Yue.
https://github.com/yue/help
>I had been the solo developer of Electron and node-webkit (now known as NW.js) for a very long time, and today big corps are building their new apps on them. So I think it should not be hard to be confident about Yue.
https://github.com/yue/help
" 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" ...
Why are you misrepresenting your work..
" 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..
>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 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.
Am I correct in my understanding that this does still use Electron? (And if so, what is it used for?)
It does not use electron, it is total native and does not use web engines, but it can be used in electron as a Node.js mudule.
What part of electron gets used? Why would it be used? Is it to package an app?
In particular, does Yue spawn the Chromium processes and Blink?
If I understand correctly, one can build JS interfaces in Yue without it, though (either with Node.js or with its Yue-specific fork, Yode). It uses Chromium base, but not Blink, right?
In particular, does Yue spawn the Chromium processes and Blink?
If I understand correctly, one can build JS interfaces in Yue without it, though (either with Node.js or with its Yue-specific fork, Yode). It uses Chromium base, but not Blink, right?
It might be a good idea to have some C++ sample apps.
> Uses native widgets;
> 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.
> 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.
Those two statements do contradict each other. According to my own quick analysis, this library uses truly native controls on Mac and GTK+, but its own windowless implementations on Windows. The Windows control implementations use uxtheme so they look more or less native, but that's not "native controls" as far as I'm concerned.
Interesting, what advantages this gives, maybe better skinning/theming support? But that doesn't seem to be the main goal of this framework...
If better skinning is the intended advantage, then it's apparently not implemented yet. I would also like to know the developer's reasoning, since using non-native controls makes it much harder to support accessibility, and this library hasn't yet addressed that.
I think it's easier to port your own drawing code from platform to platform. That's probably why Firefox and Chrome can be multi platform because their rendering code is the same.
Doing a cross platform UI library that uses native controls seems a lot of work.
Doing a cross platform UI library that uses native controls seems a lot of work.
Btw, wxWidgets uses native controls for each platform. You can even get to underlying native control and use platform specific APIs.
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.
This looks much like Sciter[0], but without declarative CSS and built-in scripting.
0. https://sciter.com/
0. https://sciter.com/
Sciter uses H/W accelerated graphics, on Windows for example it uses Direct2D/DirectX. And Yue uses GDI+ that is pure CPU based rasterization.
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.
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.
As a side note, I made an app with nodejs and vala without resorting to yue.
https://github.com/harisvsulaiman/Pushy
Its a WIP
Its a WIP
Does it have any relations to Vue.js or it's just co-branding trick?
Thank you for not doing that in JavaScript ️.
For being a library designed to assist with creating cross-platform GUIs, the website itself—which should give a good first impression of the project's attention to user interface details or user experience—is a joke.
Compounded with the other HNer's comments regarding its licensing, make your own judgments.
Compounded with the other HNer's comments regarding its licensing, make your own judgments.
I don't really like the name.
Vue Yue Vue Yue Yao Yue.
Vue Yue Vue Yue Yao Yue.
Is that as amazing as I think it is? The Electron killer, the Holy Grail of UI frameworks, the El Dorado of cross-compatibility, the One Library to rule them all?
not really, especially considering it has the same author as electron
Great job!
Maybe now we'll finally see accessible and efficient GUI apps from those who insist on writing desktop applications with JS.
Maybe now we'll finally see accessible and efficient GUI apps from those who insist on writing desktop applications with JS.
> accessible
Too bad it ignores accessibility entirely: https://news.ycombinator.com/item?id=15219025
Too bad it ignores accessibility entirely: https://news.ycombinator.com/item?id=15219025
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...
What are you talking about?
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...
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...
The author is trying to sell a freemium product, its a gift insofar as Dropbox's 2 gigs are a gift. (EDIT: maybe the premium support is more to support this project than being the main objective. I don't mean to assume too much on motives)
Some small modifications to the text can make the messaging more friendly. For example "To report a bug, please create a pull request with a test case of your problem." (instead of "you have to")
It's a small change, but conveys the same requirements without conveying a notion that the reader is a burden. Instead it just asks a favor, since we're all humans talking to each other in good faith.
It seems small, it seems pedantic, but we're guided by our emotions. The fact that this thread exists is proof that it affected at least some people enough to comment about it
Some small modifications to the text can make the messaging more friendly. For example "To report a bug, please create a pull request with a test case of your problem." (instead of "you have to")
It's a small change, but conveys the same requirements without conveying a notion that the reader is a burden. Instead it just asks a favor, since we're all humans talking to each other in good faith.
It seems small, it seems pedantic, but we're guided by our emotions. The fact that this thread exists is proof that it affected at least some people enough to comment about it
> The author is trying to sell a freemium product, its a gift insofar as Dropbox's 2 gigs are a gift.
In other words, it is a gift. You get something useful for nothing.
As for the other point, I agree that the author should use more business friendly tactics if he wishes to sell his services better, but that was not the point. The original complaint was that his approach is somewhat offensive. Which I didn't agree with. I think his approach was genuine, if not very skillful.
In other words, it is a gift. You get something useful for nothing.
As for the other point, I agree that the author should use more business friendly tactics if he wishes to sell his services better, but that was not the point. The original complaint was that his approach is somewhat offensive. Which I didn't agree with. I think his approach was genuine, if not very skillful.
No, the point made was that the author was unnecessarily aggressive. That does not imply that the author was not genuine.
The attitude of the author is definitely relevant to whether the library can and should be relied upon for inclusion in a project. Personally, this is a non-starter if I can pick up such a hostile, anti-community tone in a two minute review.
Examples:
> You can ask any question about Yue in the Issues page here, but please do not expect to get an answer.
> I know, and probably I know it better than you, I have been a long time open source project maintainer.
> 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.
The attitude of the author is definitely relevant to whether the library can and should be relied upon for inclusion in a project. Personally, this is a non-starter if I can pick up such a hostile, anti-community tone in a two minute review.
Examples:
> You can ask any question about Yue in the Issues page here, but please do not expect to get an answer.
> I know, and probably I know it better than you, I have been a long time open source project maintainer.
> 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.
> I know, and probably I know it better than you, I have been a long time open source project maintainer.
I think "I'm an engineer, to save time let's just assume I'm always right" is the maximum size for a T-shirt joke.
I think "I'm an engineer, to save time let's just assume I'm always right" is the maximum size for a T-shirt joke.
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.
The author is not a native speaker so might not be aware of how some sentences come across.
I'm not a native speaker either, but having a quite high exposure to English language, I am still puzzled at why would anyone think those sentences were hostile. Can any native speaker translate what I quoted to a non-hostile version, so we can see what's it all about?
> The issues page of this repo is disabled on purpose, 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.
Polite translation:
> The issues page of this repo is disabled. To report a bug, please create a pull request with a test case of your problem.
> For support, please go to the yue/help repo for help from the community. Paid plans are also available if you want to receive support from the project maintainers.
I wouldn't say the original is exactly impolite, but it's definitely more curt and direct than usual or than you would expect in the business world. Especially the text on the yue/help repo comes across as slightly combative or defensive in different areas. For example "You can ask any question about Yue in the Issues page here, but please do not expect to get an answer" sounds fairly dismissive to a native ear.
>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.
Polite translation:
> The issues page of this repo is disabled. To report a bug, please create a pull request with a test case of your problem.
> For support, please go to the yue/help repo for help from the community. Paid plans are also available if you want to receive support from the project maintainers.
I wouldn't say the original is exactly impolite, but it's definitely more curt and direct than usual or than you would expect in the business world. Especially the text on the yue/help repo comes across as slightly combative or defensive in different areas. For example "You can ask any question about Yue in the Issues page here, but please do not expect to get an answer" sounds fairly dismissive to a native ear.
Thanks. I got (and agree) that it was not written very skillfully, but, as you said, it was not hostile either.
To me it seemed like he was showing that he was capable of doing a fine job with Yue in which you can trust.
I totally get that, maybe it's just a question of subjective perception. What he's done is still a large piece of job.
Sorry for the unfriendly tone, some of them were written after reading some reddit comments...
And as explained in the FAQ, you can always go to the yue/help repo to report things and I will read them.
And as explained in the FAQ, you can always go to the yue/help repo to report things and I will read them.
No need to say sorry, it is clear, succinct, and reasonable. Most projects don't offer the option for premium support (which is also reasonably priced, fyi). I'm not sure what the comment above me is/was expecting.
> if you want to communicate with the author at all, even to report a bug, it'll be five thousand bucks a month...
That's not quite true - the other option is to provide a pull request with a test case showing the bug.
That's not quite true - the other option is to provide a pull request with a test case showing the bug.
[deleted]
Is the license similar to the React one?
Edit: Not trying to start a controversy or anything, I've never seen the Microsoft Reciprocal License before, it just looks like a similar idea. I'll just go look it up.
Edit: Not trying to start a controversy or anything, I've never seen the Microsoft Reciprocal License before, it just looks like a similar idea. I'll just go look it up.
5k per month for license O.o
https://github.com/yue/yue/tree/master/docs/paid_plans
https://github.com/yue/yue/tree/master/docs/paid_plans
OTOH, the license is optional. You can use it for $0.
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.
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.
I'm not expecting it to be free but 5000 usd for just for the right to not redistribute it when you modify the source, seems a bit expensive, but maybe I'm just a poor fella
Why not? If you want to modify the source, just do it in a manner that you can commit back to the repo.
I take you haven't read whats under the title contributions
https://github.com/yue/yue/tree/fb08ff884c6f9b7fb7a767dde937...
https://github.com/yue/yue/tree/fb08ff884c6f9b7fb7a767dde937...
You can redistribute your modified source code without sending a pull request.
It's just a standard grant of copyright for contributions to an open source project. Your code will still be available to you under the same license as the rest of it. It just might be incorporated in the differently licensed (paid) version.
...if you choose to modify the yue source code and not redistribute it.
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.
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.
I read the help page but I'm still not sure how this is different from Electron then? Could you care to comment?
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?
How is it basically the same?
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).
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).
Kudos for this. It does look awesome. Just tried out JS version.
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
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
> By sending a pull request, you are agreeing to transfer the copyright of your code to Cheng Zhao.
Nope.
Nope.
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.
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.
> Is there any open source project where the author retains copyright?
Yes. Pretty much all the most successful FOSS projects operate like this by default—there's no central authority and contributors retain their copyright. It's only in the last couple years or so that a weirdly high amount of orgs even started cargo culting the CLA process. And the reason for the CLAs seems to be that this was happening for nascent, quasi-corporate projects from orgs who were making their foray into open source and were under the impression that this is just how everyone else was already doing things. Meanwhile, back in reality, the old standards and posterchildren for open source were actually humming along with no CLA in sight. (E.g., Linux, Mozilla.)
The CLA trend is waning, though, as people realize that they were never necessary, they only really only introduce friction to contribution process, and the only reason anyone ever adopted them was because they were looking around and trying to emulate each other. (You know the phenomenon where someone seems to be famous just for being famous?) Projects that came about during this time (e.g. NodeJS) have actually been getting rid of their CLAs.
EDIT:
> IIRC any project with a developer agreement (like Google's) include a transferrence of copyright note.
This is not true wrt Google. Contributors retain their copyright. Where did you learn otherwise? Comments like this are how famous-for-being-famous happens.
Yes. Pretty much all the most successful FOSS projects operate like this by default—there's no central authority and contributors retain their copyright. It's only in the last couple years or so that a weirdly high amount of orgs even started cargo culting the CLA process. And the reason for the CLAs seems to be that this was happening for nascent, quasi-corporate projects from orgs who were making their foray into open source and were under the impression that this is just how everyone else was already doing things. Meanwhile, back in reality, the old standards and posterchildren for open source were actually humming along with no CLA in sight. (E.g., Linux, Mozilla.)
The CLA trend is waning, though, as people realize that they were never necessary, they only really only introduce friction to contribution process, and the only reason anyone ever adopted them was because they were looking around and trying to emulate each other. (You know the phenomenon where someone seems to be famous just for being famous?) Projects that came about during this time (e.g. NodeJS) have actually been getting rid of their CLAs.
EDIT:
> IIRC any project with a developer agreement (like Google's) include a transferrence of copyright note.
This is not true wrt Google. Contributors retain their copyright. Where did you learn otherwise? Comments like this are how famous-for-being-famous happens.
CLA = contributor LICENSING agreement. CLAs don't need to include transfer of copyright.
A CLA is still necessary in some form in this case for the owner of the repo to re-license the product under the commercial dual licensing scheme.
A CLA is still necessary in some form in this case for the owner of the repo to re-license the product under the commercial dual licensing scheme.
I don't understand what point you're trying to make. The tone of your comment comes across as if you're refuting/disputing something (that may be implied?) in what I wrote, but I'm not sure what it is.
You can transfer the right to publish/sub-license your contributions under their commercial license without transferring copyright.
While a CLA is necessary for a dual-licensed project, it doesn't have to include a transfer of copyright, and many don't. E.g. Google's doesn't, the one for Python doesn't. On the other side, the ones for MongoDB and the FSF do. (At least MongoDB's is also clever enough to have a fallback to pure licensing, since "transfer of copyright" isn't possible in some jurisdictions)
And of course there are tons of Open-Source projects that don't have CLAs at all.
And of course there are tons of Open-Source projects that don't have CLAs at all.
E.g., Linux and GNOME
Don't send a Pull Request, then.
I don't get why you're so attached to a PR you make to another library. So you're not contributing because you want to improve that other library, you're contributing because you want to sue them after so theycan pay you for your share of the project since you've added 10 lines of code?
I guess it is a combination of factors.
As stated else where it seems like author has copied/forked existing project. Then (if I understood the license correctly) you are required to open source your software if you were to use the library, or pay $5k. On top of that if you contribute to the project you sign away your copyright.
If these things are correct it seems like a one hot mess of a project.
As stated else where it seems like author has copied/forked existing project. Then (if I understood the license correctly) you are required to open source your software if you were to use the library, or pay $5k. On top of that if you contribute to the project you sign away your copyright.
If these things are correct it seems like a one hot mess of a project.
From the FAQ, https://github.com/yue/help
> 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.
> 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.
That's for modifying Yue's code, not your code.
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:
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.The README on the other hand states:
> The Yue project is under the Microsoft Reciprocal License (MS-RL) with following clarifications: [...]
Using a modified version of this software is considered as containing this software's code, so any code linked to it has to be licensed under MS-RL.
That at least to me reads like a different interpretation, which is worrysome.
> The Yue project is under the Microsoft Reciprocal License (MS-RL) with following clarifications: [...]
Using a modified version of this software is considered as containing this software's code, so any code linked to it has to be licensed under MS-RL.
That at least to me reads like a different interpretation, which is worrysome.
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.
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.
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.
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.
Linking with the code of this software in any form is not considered as containing its code
As long as you don't make any changes, sounds like it's free and unrestricted.
As long as you don't make any changes, sounds like it's free and unrestricted.
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/...