You can supply the object file in stead of the source code.mar wrote:Which you obviously can't do without having the source code when you link statically, ergo I was correct. Linking statically implies the release of full source code of your program.Fulvio wrote:With both static and dynamic linking the user must retain the freedom to modify a LGPL library, even if it's used in a closed source project, and the only requirement is the ability to relink the application.
Do patches need to be open source?
Moderators: hgm, Rebel, chrisw
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Do patches need to be open source?
-
- Posts: 395
- Joined: Fri Aug 12, 2016 8:43 pm
Re: Do patches need to be open source?
Incorrect again, but i will not waste time explaining how linking works: you can google it.mar wrote: Which you obviously can't do without having the source code
-
- Posts: 2559
- Joined: Fri Nov 26, 2010 2:00 pm
- Location: Czech Republic
- Full name: Martin Sedlak
Re: Do patches need to be open source?
Let's assume this would work (I'm still not convinced the license would allow this, but I'm no lawyer).hgm wrote: You can supply the object file in stead of the source code.
The object files are much bigger than the resulting binary, can be 30:1 or more so nobody would do that (for one of my projects it's 70MB on disk vs 1.6MB binary, one platform).
Now multiply this by the number of platforms you want to support, say you want to write for Linux and OSX, that's times 3, so for a 1 MB app that could be, say 50MB compressed that you have to distribute along with your app.
Not to mention that it's likely that you might not be able to link with some future CRT with a new version of the compiler.
So under realistic scenarios, it's better to link dynamically, release the source or stay away from LGPL.
-
- Posts: 2559
- Joined: Fri Nov 26, 2010 2:00 pm
- Location: Czech Republic
- Full name: Martin Sedlak
Re: Do patches need to be open source?
A cheap non-argument, feeling cocky?Fulvio wrote: Incorrect again, but i will not waste time explaining how linking works: you can google it.
Are you serious to lecture me about how linking works?
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Distributing object files with existing binary is impractical (let's avoid being rude calling it nonsense) for reasons I explained in another post.
-
- Posts: 395
- Joined: Fri Aug 12, 2016 8:43 pm
Re: Do patches need to be open source?
I do not see any benefit in your provocations.mar wrote: A cheap non-argument, feeling cocky?
Are you serious to lecture me about how linking works?
This is a public forum and you are spreading false information, that's my only concern.
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: Do patches need to be open source?
So you are saying that distributing a library that contains no GPL'd material from Stockfish whatsoever could not be distributed under another license than the GPL? That is of course false.Ras wrote:Because it's dynamically linked AND shares data structures. This is exactly what the GPL defines, and that is part of the point of the GPL.syzygy wrote:But I think it's still fine. I see no reason why some library that maybe does not even exist or that may not be uniquely identifiable would somehow become part of "the entire work".
You can sell GPL'ed software, too.Maybe I have an advanced proprietary version of the library that I sell for good money and a toy version that I give away for free including the GPL'd source.
It doesn't change it. It has always been that way.Would the fact that the proprietary version exists suddenly change the "entire work" that has to be licensed under the GPL?
Then he has the same problem. The point of the GPL is to prevent people from taking free SW, tacking proprietary stuff on top of it and making it non-free. Dynamic linking is not exempted under the GPL. Authors use the GPL to explicitely prevent that kind of circumventing. If they had wanted to allow that, they could have chosen e.g. BSD or MIT instead.What if that proprietary version is not even written by me but by someone else?
Stockfish can, of course, but the library designed to run with Stockfish can't. And if there is only the closed lib, then the modified Stockfish version can't be distributed either - except by the authors who can chose dual-licencing, of course.Stockfish can no longer be distributed unless that new library is GPL'd?
The only thing that could become illegal to distribute (because someone writes a proprietary replacement library that happens to offer the API that SF uses) is SF itself. But of course that is equally ridiculous!
The "entire work" concept of the GPLv3 simply makes no sense and is therefore likely unenforceable.
-
- Posts: 5566
- Joined: Tue Feb 28, 2012 11:56 pm
Re: Do patches need to be open source?
You said it can't be done without distributing the source, and obviously it can be done without distributing the source, so why not simply admit that you got it wrong... There is no shame in admitting a mistake.mar wrote:A cheap non-argument, feeling cocky?Fulvio wrote: Incorrect again, but i will not waste time explaining how linking works: you can google it.
Are you serious to lecture me about how linking works?
Distributing object files with existing binary is impractical (let's avoid being rude calling it nonsense) for reasons I explained in another post.
-
- Posts: 2559
- Joined: Fri Nov 26, 2010 2:00 pm
- Location: Czech Republic
- Full name: Martin Sedlak
Re: Do patches need to be open source?
Even if it could be done this way (assuming the license would allow that), it'd be impractical to do so - so not really a practical option.syzygy wrote:You said it can't be done without distributing the source, and obviously it can be done without distributing the source, so why not simply admit that you got it wrong... There is no shame in admitting a mistake.
I'd like to see a single project that links statically and distributes object files this way.
So even if I'd admit that it "can be done", it's so annoying that nobody does that. Yes, you can hit a nail with a plane but nobody does that for obvious reasons.
-
- Posts: 4556
- Joined: Tue Jul 03, 2007 4:30 am
Re: Do patches need to be open source?
Sharing is done to ACTUAL, REAL people, you don't just share to hypothetical people that could benefit from your work.MikeB wrote:You do know the whole point of being open source is to share.
I had my doubts on this, but it seems clear nobody posting on this thread is from the actual people that would benefit and be grateful if something like this was released as open source, so I'm glad this is remaining private.
The problem with open source is that the thing is shared to everyone equally, it doesn't matter if they deserve it or not.
So I'm currently thinking there are things that should only be shared to people that will appreciate it, because if it was distributed to everyone people like Mr. Dann "We can live without it" Corbit would also get their hands on it.
Disclaimer: Of course, I didn't implement some Learning Algorithm in Stockfish
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
Your beliefs create your reality, so be careful what you wish for.
-
- Posts: 1600
- Joined: Mon Feb 21, 2011 9:48 am
Re: Do patches need to be open source?
If this is the case, you don't need to distribute these large files either, a download link is sufficient.mar wrote:Even if it could be done this way (assuming the license would allow that), it'd be impractical to do so - so not really a practical option.syzygy wrote:You said it can't be done without distributing the source, and obviously it can be done without distributing the source, so why not simply admit that you got it wrong... There is no shame in admitting a mistake.
I'd like to see a single project that links statically and distributes object files this way.
So even if I'd admit that it "can be done", it's so annoying that nobody does that. Yes, you can hit a nail with a plane but nobody does that for obvious reasons.
For example in Stockfish it is not necessary to download the code to have an executable.