GPL user restrictions ? (Developers)
> > > If they only use a LGPL library for another program, the other
> program
> > > explicitly doesn't have to be GPL.
> >
> > Ah, but then are you are talking about when it is formally a separate
> > library.
>
> I think you meant "library" as in, well, library. A separate binary. Its
> code is called from other programs. GPL source libraries of course can't
> be used for non-GPL programs.
I meant originally more as in a set of reusable routines. Doesn't matter how exactly they are packages. (since if open that can change if not hampered by license)
> > Well, if you mean that about the only use of the LGPL is that it isn't
> > GPL, then you are right
>
> Well, no, I meant that it's only use is that "the other program [using the
> library] explicitly doesn't have to be GPL".
I think we are saying the same thing here 
> > If, in your own words, it matters so little to have the source,
>
> First: Not my words. I said for users.
There are no pure users and pure developers. Even people that don't compile themselves might use binaries that are not generated by the original copyrightholder.
> > I wonder why the advocatists are so big on keeping source live.
>
> To keep the program free.
Then why exclude a large section of people? That is not my kind of freedom.
> That's the concept of Copyleft. (Of course
> enforced Copyleft is what prohibits use in proprietary programs, so that's
> what you are criticizing after all.)
Exactly. And I know exactly how it works. The point is that the cure is IMHO worse than the problem.
> And you didn't answer my question.
If you mean this one:
> What do you mean by "never use anything with a
> different license"?
I meant that if you are a mere Linux distro user that has most of the license choices made for him, precooked, then, from that helicopter view everything looks peachy.
> > They cannot for drivers afiaik. The commercial driver must use
> userspace
> > workarounds as a loophole
>
> I don't know. Only thing I heard is that there are some proprietary Linux
> drivers. (BTW, as the FSF says: please
> avoid
> the word "commercial" if you mean non-free software. Commercial free
> software is also possible.)
I use the Websters dictionary, not GNU's. Excluding 99.9% of normal commercial use, and then pointing to a small loophole that is possible is a great for advocatists, and useless for the rest.
> > That's because dos drivers communicate with the kernel over interrupts.
>
> No they don't. Don't let terms like "device strategy and device interrupt
> calls" fool you. They communicate over calls from the kernel directly into
> the device driver's code, which (despite one being called device interrupt)
> don't use any interrupts at all.
Then, if the kernel is GPL, and there are no special conditions, and the devicedrivers are GPL incompatible, to my best knowledge that is a license violation.
> I didn't compare them to either and I don't know more about either anyway.
> I compared DOS drivers to plugins, which I imagine as similar to DLLs. DLLs
> in turn are often used as plugins on Windows, and even with some DOS
> extenders. My intention is this: as close as DOS drivers are to their
> kernel, presumably without being affected by the kernel's GPL, how can the
> GPL affect plugins which technically are much less tied to their main
> program?
If you combine code in pieces to a large work, the larger work is covered by the GPL. The definition is a linking process. If the dos device drivers hook up to the kernel via some linking process rather than a interrupt or a trap, the GPL applies, and it is no different from DLLs.
> So because the DOS driver interface didn't change for 20-what years, any
> DOS driver is linked into/for my GPL DOS kernel?
It could be yes. It depends on how the loading process works exactly. Maybe if they are loaded straight (no relocation, not even segments) and they call fixed numbers in a calltable, a case could be made that no relocation is performed.
> I hope you weren't
> talking about the DOS drivers here anymore, but I won't say writing
> plugins which reside in different binaries as the main program counts as
> linking them together either.
Well, I _explicitely_ asked the GNU foundation that, and I got an e-mail back from Stallmanns secretary, and he stated it is explicitely so.
> > The exact extend to what constitute linking in inter-process
> communcation
> > is not clear to me. It is a gray area.
>
> Which results in that the MPL plugins for the GPL program aren't exactly
> covered by the GPL's Copyleft.
MPL is not GPL compatible. If there is no special exception for the plugin interface, you don't have a license to use GPL code anymore as soon as you combine it with MPL
> > (snip totally random pieces of GPL license text, what were they meant
> to > convey? (pun intended))
>
> First off, I didn't get the pun, maybe because English isn't my first
> language.
(it was a bad pun, convey is about every other word in the GPLv3 text)
> Then, I added these snippets (they're neither total nor random)
> after the discussion of GPL main program vs. MPL/other license plugins.
> Essentially here: since the program only interfaces with the plugin's
> binary while running, you can use the main program disregarding the
> GPL with your incompatible licensed plugins (if the GPL really covers
> that plugins have to be GPL too).
Ah, correct, good point, and one I overlooked. So it only means you can't distribute the program and its plugins (though that was what I said originally about the lazarus case btw)
> > The whole Lazarus example is btw just meant to illustrate that it is
> > pretty hard to forsee the consequences of choosing an extremely
> > restrictive license as GPL.
>
> Oh. Then, I come to the conclusion that I can only agree with you on that:
> it is pretty hard to forsee the consequences of choosing an extremely
> restrictive license. Plus, yes, the GPL is extremely restrictive
> when you want to use source code for proprietary programs.
Well that is the point. You might know that up front. And the GPL is actually of some use in really critical cases. But too much projects and code just gets a GPL slapped on by young idealistic idiots in their student years, when they don't have a clear picture of the daily reality of staying in Open Source after university.
I know. I was one.
It helps tremendously if you can work on some open source bits at work, but that is hard to make that happen if you can't use the result. A few really big corporations can finance the kernel, GCC, KDE and Gnome, no matter the license, for some big spearpoint in their strategies.
But the smaller packages are helped out by developers working in smaller and medium companies, and also by big business more low-profile.
And then the GPL leads to a lot of double work, also in the open source community, by parties that are not as fanatic. And that extra work and limitations caused by that conflict within the open source community hurts open source, not evil commercial companies. (who wouldn't touch either probably because their legal division is paranoid)
Complete thread:
- New RxDOS memory subsystem source code - ecm, 15.06.2009, 21:33 (Developers)
![Open in board view [Board]](img/board_d.gif)
![Open in mix view [Mix]](img/mix_d.gif)
- New RxDOS memory subsystem source code - Japheth, 16.06.2009, 17:21
- New RxDOS memory subsystem source code - ecm, 16.06.2009, 21:23
- GPL vs. BSD - Rugxulo, 19.06.2009, 06:54
- GPL vs. BSD - marcov, 20.06.2009, 14:09
- GPL vs. BSD - Rugxulo, 21.06.2009, 04:37
- GPL vs. BSD - marcov, 21.06.2009, 14:30
- GPL vs. BSD - Rugxulo, 22.06.2009, 10:11
- GPL vs. BSD - marcov, 22.06.2009, 16:07
- GPL user restrictions ? - ecm, 23.06.2009, 00:35
- GPL user restrictions ? - marcov, 23.06.2009, 10:11
- GPL user restrictions ? - ecm, 23.06.2009, 13:05
- GPL user restrictions ? - marcov, 23.06.2009, 16:39
- GPL user restrictions ? - ecm, 23.06.2009, 20:55
- GPL user restrictions ? - Khusraw, 24.06.2009, 20:08
- Commercial philosophs - ecm, 25.06.2009, 02:51
- Commercial philosophs - Khusraw, 25.06.2009, 08:47
- Commercial philosophs - ecm, 25.06.2009, 16:31
- Commercial philosophs - Khusraw, 25.06.2009, 16:50
- Commercial philosophs - marcov, 25.06.2009, 21:44
- Commercial philosophs - ecm, 25.06.2009, 23:34
- Commercial philosophs - marcov, 27.06.2009, 14:09
- Commercial philosophs - Khusraw, 28.06.2009, 13:16
- Commercial philosophs - Rugxulo, 01.07.2009, 22:52
- Commercial philosophs - ecm, 25.06.2009, 23:34
- Commercial philosophs - ecm, 25.06.2009, 16:31
- Commercial philosophs - Khusraw, 25.06.2009, 08:47
- Commercial philosophs - ecm, 25.06.2009, 02:51
- GPL user restrictions ? - marcov, 25.06.2009, 21:24
- GPL user restrictions ? - ecm, 26.06.2009, 11:27
- GPL user restrictions ? - marcov, 26.06.2009, 23:59
- GPL user restrictions ? - ecm, 26.06.2009, 11:27
- GPL user restrictions ? - Khusraw, 24.06.2009, 20:08
- GPL user restrictions ? - ecm, 23.06.2009, 20:55
- GPL user restrictions ? - marcov, 23.06.2009, 16:39
- GPL user restrictions ? - ecm, 23.06.2009, 13:05
- GPL user restrictions ? - marcov, 23.06.2009, 10:11
- GPL user restrictions ? - ecm, 23.06.2009, 00:35
- GPL vs. BSD - marcov, 22.06.2009, 16:07
- GPL vs. BSD - rCX, 25.06.2009, 18:01
- GPL vs. BSD - Rugxulo, 22.06.2009, 10:11
- GPL vs. BSD - marcov, 21.06.2009, 14:30
- GPL vs. BSD - Rugxulo, 21.06.2009, 04:37
- GPL vs. BSD - marcov, 20.06.2009, 14:09
- GPL vs. BSD - Rugxulo, 19.06.2009, 06:54
- New RxDOS memory subsystem source code - ecm, 16.06.2009, 21:23
- New RxDOS memory subsystem source code - ecm, 03.05.2018, 12:55
- New RxDOS memory subsystem source code - rr, 28.10.2018, 19:44
- New RxDOS memory subsystem source code - ecm, 05.11.2018, 14:24
- New RxDOS memory subsystem source code - rr, 05.11.2018, 20:52
- New RxDOS memory subsystem source code - ecm, 05.11.2018, 14:24
- New RxDOS memory subsystem source code - rr, 28.10.2018, 19:44
- New RxDOS memory subsystem source code - Japheth, 16.06.2009, 17:21
Mix view