More permissive licensing about darling HOT 13 CLOSED

The real total contributor count is more like 2, other people's contributions are either marginal or have been rewritten since. And most of the second contributor's code is located in libmach-o, as the dynamic loader has been recently rewritten.

The motivation behind GPL is to prevent 3rd parties from monetizing Darling without sharing the code or profit (at least). And I know there may be companies interested in doing that in order to provide a commercial iOS->Android porting solution.

Darling is not supposed to be used for building software. By that I mean "not intended for" and "not designed for" at the same time. I'll explain this in more detail:

Not intended for: There is no point to use it for building when you can run it directly from original binaries. Should Darling lack some needed features for this, it is better to add them. Not even winelib has been used extensively for this purpose (and the resulting apps sucked anyway).

Not designed for: Darling's header files are typically designed for a C++/ObjC++ compiler even if they contain C/ObjC-only API. The header files also don't precisely follow the ones on Apple in other regards - e.g. they never contain macros, since those are not part of ABI. The declarations may also exist in different files than on OS X.

from darling.

Just because different parts of Darling use incompatible licenses, doesn't mean that the result cannot be distributed. If you compile a GPL-licensed app on OS X, you can still distribute the resulting binary, even though parts of OS X are licensed under APSL.

I find it rather sad, however, that there are more people talking about the right license and almost nobody contributing code :-(

from darling.

To quote Linus Torvalds:

Nobody has the right to whine about another persons choice of license. You have a choice: use it or don't. Complaining about the license to the author isn't part of it.

from darling.

When choosing open source libraries for my projects, I always avoid copyleft licenses, because they limit my freedom (including my freedom to release any derived works under MIT license, for example). If SDL 2 was copylefted, I wouldn't be using it. The same happens when I release code, I never choose copyleft because I wish my code will be used by everybody, no matter their licensing preferences. Copyrighted open source pleases everybody (copyleft developers included).

Yes, as you said, others can monitize your effort. You don't get their money, but you get maximum possible deployment for your work.

As others said, everybody is free to choose their license. I respect it. I'm only saying that if Darling had some use (as a lib, for example) inside another software, I wouldn't use it in a project of mine unless it was MIT/BSD/etc licensed.

I'm not pickier than others. Otherwise, quite a few commercial companies wouldn't be offering a copyleft license for free and a copyright license if you pay. Nobody would buy such licenses if my preferences weren't popular. The deal they offer is freedom for money. MIT/BSD/etc licenses offer maximum freedom for free.

EDIT: That said, however, Darling is a unique product. Your effort deserves to be highly rewarded. If you wish others not being able to release commercial products based on yours, you have the right to do so. If you even wish to release your own commercial license at some point, I wish it to be a huge success. Darling is unique. But, if your goal is maximum widespread use of Darling for whatever purpose, then the way to go is MIT/BSD/etc.

from darling.

@cesss It's not at straightforward as you're trying to make it sound. Copyleft vs permissive is a highly debatable topic, the argument for copyleft (that does not necessarily represent my opinion) being that despite copyleft licenses limiting some of your freedoms (namely, the freedom to distribute modified work without making it copyleft), they give you more freedom in the long term, because they ensure that no proprietary fork can overtake the original (or even exist) -- others are forced to give their work back to the community, and in the end everyone gets a better product.

But, if your goal is maximum widespread use of Darling for whatever purpose, then the way to go is MIT/BSD/etc.

Well, if you compare the popularity of BSD to that of GPL'ed GNU & Linux... On the other hand, see the iOS situation: it uses code from FreeBSD, Apple makes crazy profits from it, but doesn't want to open-source it -- still, Linux (in the form of Android) is more popular.

from darling.

The LGPL used by WINE should achieve your goal without the risk of alienating developers. I realize that compilation is not presently a goal for you, but as your project moves forward, the opportunity to start building stuff could arise. A potential use case would be iOS development on Linux. I know that Saurik does this currently, but he is one of the few capable of doing that at this time.

A more attainable use case would be building Gentoo Prefix inside Darling. By the time that is possible, Gentoo's cross compilation tools would likely be ported to Gentoo Prefix, allowing Darling to easily self host itself by means of the Gentoo Prefix environment. If Darling matures enough, I could see Gentoo developers without access to Mac OS X using it to test updates to ebuilds that they maintain that are available on Mac OS X. Licensing is not a problem for that as none of them would be redistributing binaries, but it does illustrate the usefulness of being able to compile inside Darling. Even if compilation is not a current goal, it might be wise to pick a license that is ready for a future where compilation inside Darling is feasible.

from darling.

+1

from darling.

+1

from darling.

I've already used Darling to crosscompile (simple) OS X binaries and I think it would be usable for Gentoo Prefix already. There used to be some random crashes, but I didn't see them last time I checked - I will recheck. The OS X SDK has everything needed for this, including header files and fake dynamic libraries. In other words, Darling's header files are not used at all.

But using Darling's header files wouldn't infringe copyright anyway IMO - only distributing proprietary code along with Darling's binaries would.

That being said, I will consider LGPL for Darling's frameworks (i.e. not for libdyld that I'll soon split away from dyld).

from darling.

@LubosD I would also like to chime in on this. I agree with the points made by @ryao above. In addition, it is my understanding (although IANAL) that the Apple Public Source License and the GPL (any version) are not compatible, which means that mixing code under those licenses and distributing it is not possible without violating the terms of the GPL.

If I may suggest, would you consider relicensing (part of) Darling under the Mozilla Public License version 2.0? This license still requires that modified source files be released, which was your main concern as stated above, but it does not place as many restrictions on Darling users as the LGPL does. (For example, the LGPL requires that the user be able to replace the LGPLed code with their own, modified versions and have the app still launch. This is not possible on any of the popular "app store" platforms due to code-signing requirements that prevent modified apps from launching, even if the modification is permitted by the software vendor.)

from darling.

It might be worth contacting the FSF about this. Back when the OpenCard/FreeCard project was a thing, we actually got them to come up with an exception clause we could add to our code that made it GPL, but allowed people to build standalone versions of their documents that embedded the application without them being considered derivative works. Admittedly, that was over a decade ago, but they were very polite and forthcoming back then.

from darling.

Well, can you change the license from GPLv3 to GPLv2, because this project possibly could become a part of the Linux kernel for better binary compatibility for *BSD (and Mac) software.

from darling.

@bugaevc In fact the copyleft vs copyright discussion doesn't have practical/tech roots. There's a deeper root in the debate. However, when writing my point above, I focused in a practical consequence of such choice, and that's the reason why I said if Darling had some use (as a lib, for example) inside another software. The GNU promoters acknowledge the practical difference between software meant to be used by end-users and software meant to be used by developers as a component inside another software project.

The only reason why the LGPL exists is because GNU promoters realized the freedom limits imposed by the GPL would be found not acceptable by quite a few developers when using third-party libraries or code. If the GPL was abandoned within libraries, the copyleft cause would be harm, so they introduced LGPL as a half-copyleft that could help push the cause even in such scenarios.

Note that the GPL-success examples you mention are end-user based. Note also that end-users don't usually worry about licenses (otherwise closed source wouldn't have more users than open source). If you think about developer reusable code, you'll soon find examples where the choice of a copyright license helped the project to become widespread both in copyright and in copyleft environments (X11 just to name one), while if they had chosen a copyleft license, they would limit the potential number of developers using it.

When choosing libraries for my projects, I always require them to not be copyleft (not even LGPL). When choosing applications, I prefer non-copyleft because I never know if I'll have some idea in the future about starting a derived project from it. But I use some GPLed applications when there's no MIT/BSD alternative, or when they are unique in their class (as Darling is, for example).

Back to Darling, I insist the effort done deserves to be rewarded, and it's always the developers who must choose if it's copylefted or not. From my perspective, I can use Darling even if it is GPLed. But, if at some point, Darling becomes a sort of library or reusable component, is quite unlikely I'll use it for starting a new project (although I'll use it as a standalone application, of course).

from darling.