Forwarded from: marcov@stack.nl (Marco van de Voort)
(Sorry, it's a bit late. I had overlooked it.)
On 2006-02-25, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
However, as I've said before, I'm skeptical about Input etc. Do we really want a per-thread Input, each with its own buffer (which means, if several of them are acutally used, it becomes hard to foretell in which one each sequence of input bytes ends up)? Similar for Output. For StdErr, one could argue that it shouldn't buffer at all (which GPC's in fact doesn't, and so does stderr in C by default AFAIK).
This is a possible problem, buffering also complicates initialisation of a new thread, because it requires more than a shallow copy of the threadvar segment. (buffer is duplicated, stuff in output is thus twice in buffer, not to speak about what if you use pointers in the filedescriptor record etc).
There are bugreports about problems with threadsafe input/output in FPC bugrepository, mostly in combination with unit crt.
There's a few more in TP-compatibility units (like doserror in the Dos unit and some crt things)
Well, for CRT, just making the internal state per-thread wouldn't really help much AFAICS. E.g., if each threads has its own screen buffer, and updates the real screen from it, this would probably result in chaos. IOW, as there's only one physical screen (unless multi-headed), I think one probably needs some common data across threads. Or you leave it up to the user -- as, e.g., ncurses recommends doing all curses I/O within one thread.
The latter thing is a typical thing for UIs. E.g. Delphi also specifies the VCL (GUI classes) as non-threadsafe. It provides a synchronization mechanism though to schedule basic code in the mainthread.
Since our RTL is under a slightly modified LGPL (allows static linking as long as you make the modifications to the FPC-RTL-licensed code available), license-wise I don't think there is any problem for you to reuse things. If there is, we could dual-license it under the regular LGPL as well I suppose (the main reason for the static linking exception is that some OS'es, like Dos, simply do not support dynamic linking, and support for creating dynamic libraries was not available for all OS'es in our compiler from the start either).
BTW, standard LGPL allows static linking as well. You just have to distribute object files of the non-free parts, so users can relink. But I suppose for some reason that's not desired?
No. I think we simply didn't think of that, and the GNU site didn't spell it out either. It is a good point for the license FAQ though.
Since our RTL is under a slightly modified LGPL (allows static linking as long as you make the modifications to the FPC-RTL-licensed code available), license-wise I don't think there is any problem for you to reuse things. If there is, we could dual-license it under the regular LGPL as well I suppose (the main reason for the static linking exception is that some OS'es, like Dos, simply do not support dynamic linking, and support for creating dynamic libraries was not available for all OS'es in our compiler from the start either).
BTW, standard LGPL allows static linking as well. You just have to distribute object files of the non-free parts, so users can relink. But I suppose for some reason that's not desired?
No. I think we simply didn't think of that, and the GNU site didn't spell it out either. It is a good point for the license FAQ though.
The above is not true, there are more requirements of a statically linked LGPL than the above. But even if that were the only requirement, it is a fairly onerous one to put on developers. The LGPL also requires copyright notices, as well as distribution of the RTS source.
Surely the intention of the compiler is to allow people to compile their applications and distribute them as they choose without restrictions simply due to using the RTS?
Requiring everyone using GPC with a non-free program to ship an executable as well as a separate object module that could be linked with a separately compiled RTS seems entirely pointless.
There is very good reasons for static linking the RTS to not bring in any part of the GPL or LGPL license.
At least in my opinion, as both a minor contributor and a commercial developer. Peter.
Peter N Lewis wrote:
Since our RTL is under a slightly modified LGPL (allows static linking as long as you make the modifications to the FPC-RTL-licensed code available), license-wise I don't think there is any problem for you to reuse things. If there is, we could dual-license it under the regular LGPL as well I suppose (the main reason for the static linking exception is that some OS'es, like Dos, simply do not support dynamic linking, and support for creating dynamic libraries was not available for all OS'es in our compiler from the start either).
BTW, standard LGPL allows static linking as well. You just have to distribute object files of the non-free parts, so users can relink. But I suppose for some reason that's not desired?
No. I think we simply didn't think of that, and the GNU site didn't spell it out either. It is a good point for the license FAQ though.
The above is not true, there are more requirements of a statically linked LGPL than the above.
Of course, I didn't quote the full license text, but only mentioned the main relevant diffrence between static vs. dynamic linking.
But even if that were the only requirement, it is a fairly onerous one to put on developers.
Have you done it? I have. So I think I can tell it's doable. I don't think it's particularly difficult either, 2-3 more lines in my Makefile or so.
The LGPL also requires copyright notices,
If you make changes to it. (Otherwise you just copy the existing code with the existing copyright notices.) AFAICS, this is no different with the FPC exception.
Requiring everyone using GPC with a non-free program to ship an executable as well as a separate object module that could be linked with a separately compiled RTS seems entirely pointless.
Actually, we're not talking about the GPC RTS here, but FPC's modified LGPL. I also wasn't objecting to these modifications, BTW, just pointing out that the standard LGPL does not require dynamic linking when used with differently licensed code, which is a common misunderstanding.
BTW, looking closer at the modifications, I see a possible problem, though unrelated to the issue at hand (and this might not be the right place to discuss it): Someone could make changes to the library, not release them ((L)GPL doesn't require it), and then release a program that uses that modified library under a proprietary license by the exception, so in effect the library changes, though clearly based on the library, would never be released under a free license.
There is very good reasons for static linking the RTS to not bring in any part of the GPL or LGPL license.
That might be a misunderstanding. If the RTS were under the plain (L)GPL, then its conditions would also (or especially) apply with static linking.
Frank
At 12:48 +0100 20/3/06, Frank Heckenbach wrote:
Peter N Lewis wrote:
But even if that were the only requirement, it is a fairly onerous one to put on developers.
Have you done it? I have. So I think I can tell it's doable. I don't think it's particularly difficult either, 2-3 more lines in my Makefile or so.
It's not so much the actual creation, its the whole distribution channel that is then required. You need to either include the extra object and the source of the library in the distribution, or maintain a second version at the source site which needs to be kept for three years. You couldn't maintain the spirit of the rules when other people redistribute your software (eg versiontracker.com, magazine CDs). If a version needs to be pulled entirely (due to a security or data trashing problem for example), you could not do it, as the faulty version would need to be kept around for three years.
The LGPL also requires copyright notices,
If you make changes to it. (Otherwise you just copy the existing code with the existing copyright notices.) AFAICS, this is no different with the FPC exception.
Yes, you need to display library copyright notes, that's what I meant.
LGPL:
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License.
So that probably means notices in the About box. It's not clear how the version information for the bundle, which includes a tiny amount of space for a copyright, would be affected - it couldn't include it, yet it might be interpreted that it must include it.
I don't really object to licenses and copyright notices in the docs, especially for a real LGPL library, but I don't believe just using the RTS of the compiler should have such requirements. Mind you, at least there is no equivalent to the OpenSSL press release debacle.
Actually, we're not talking about the GPC RTS here, but FPC's modified LGPL. I also wasn't objecting to these modifications, BTW, just pointing out that the standard LGPL does not require dynamic linking when used with differently licensed code, which is a common misunderstanding.
Agreed.
There is very good reasons for static linking the RTS to not bring in any part of the GPL or LGPL license.
That might be a misunderstanding. If the RTS were under the plain (L)GPL, then its conditions would also (or especially) apply with static linking.
Yes, absolutely. Which is why I'm glad there is an exception for linking to the GPC RTS. I'll have to go and read the FPC RTS license, since if it really is LGPL-like, depending on what the differences are that may be a reason to use GPC over FPC. Peter.
Peter N Lewis wrote:
It's not so much the actual creation, its the whole distribution channel that is then required. You need to either include the extra object and the source of the library in the distribution, or maintain a second version at the source site which needs to be kept for three years. You couldn't maintain the spirit of the rules when other people redistribute your software (eg versiontracker.com, magazine CDs). If a version needs to be pulled entirely (due to a security or data trashing problem for example), you could not do it, as the faulty version would need to be kept around for three years.
Yes, the 3 years option is a bit cumbersome. I've always done c) (for net distribution) or a) (for CDs). I don't see the big problem of putting one or two more files in a web directory or on a CD.
If other people redistribute it, it's their obligation to obey the license (LGPL and your license for the rest).
Yes, you need to display library copyright notes, that's what I meant.
LGPL:
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License.
So that probably means notices in the About box. It's not clear how the version information for the bundle, which includes a tiny amount of space for a copyright, would be affected - it couldn't include it, yet it might be interpreted that it must include it.
I'm not sure what you mean by the latter. What do you mean by "version information for the bundle"? If it's something that the program displays, then yes, it seems it must include the LGPL copyright (but why couldn't it?), otherwise I don't think it must.
I don't really object to licenses and copyright notices in the docs, especially for a real LGPL library, but I don't believe just using the RTS of the compiler should have such requirements.
Actually I think we all agree here.
Mind you, at least there is no equivalent to the OpenSSL press release debacle.
Which debacle?
There is very good reasons for static linking the RTS to not bring in any part of the GPL or LGPL license.
That might be a misunderstanding. If the RTS were under the plain (L)GPL, then its conditions would also (or especially) apply with static linking.
Yes, absolutely. Which is why I'm glad there is an exception for linking to the GPC RTS. I'll have to go and read the FPC RTS license, since if it really is LGPL-like, depending on what the differences are that may be a reason to use GPC over FPC.
No, I don't think so. (Though, of course, I think there are other reasons to use GPC over FPC. :-) For the license issue, both seem to have rather similar effects.
Frank
At 10:23 +0100 21/3/06, Frank Heckenbach wrote:
Peter N Lewis wrote:
So that probably means notices in the About box. It's not clear how the version information for the bundle, which includes a tiny amount of space for a copyright, would be affected - it couldn't include it, yet it might be interpreted that it must include it.
I'm not sure what you mean by the latter. What do you mean by "version information for the bundle"? If it's something that the program displays, then yes, it seems it must include the LGPL copyright (but why couldn't it?), otherwise I don't think it must.
Thats why its gray. The program includes an info string which is a copyright notice, which is displayed by the system (Finder) in response to the Get Info for the application. Technically, its not displayed "by the program", but it is part of the program, and its a copyright notice, and its displayed as the program. But it's very small, not enough room for multiple copyright notices.
I don't really object to licenses and copyright notices in the docs, especially for a real LGPL library, but I don't believe just using the RTS of the compiler should have such requirements.
Actually I think we all agree here.
Yup.
Mind you, at least there is no equivalent to the OpenSSL press release debacle.
Which debacle?
They require two different notices to be included in any press release:
*** This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. http://www.openssl.org/
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com) ***
There is very good reasons for static linking the RTS to not bring in any part of the GPL or LGPL license.
That might be a misunderstanding. If the RTS were under the plain (L)GPL, then its conditions would also (or especially) apply with static linking.
Yes, absolutely. Which is why I'm glad there is an exception for linking to the GPC RTS. I'll have to go and read the FPC RTS license, since if it really is LGPL-like, depending on what the differences are that may be a reason to use GPC over FPC.
No, I don't think so. (Though, of course, I think there are other reasons to use GPC over FPC. :-) For the license issue, both seem to have rather similar effects.
Good to know, it'd be a shame if license issues were a reason for making the decision (and I agree, I think there are lots of good reasons to use GPC over FPC, but it's nice to have FPC too). Peter.
Peter N Lewis wrote:
At 10:23 +0100 21/3/06, Frank Heckenbach wrote:
Peter N Lewis wrote:
So that probably means notices in the About box. It's not clear how the version information for the bundle, which includes a tiny amount of space for a copyright, would be affected - it couldn't include it, yet it might be interpreted that it must include it.
I'm not sure what you mean by the latter. What do you mean by "version information for the bundle"? If it's something that the program displays, then yes, it seems it must include the LGPL copyright (but why couldn't it?), otherwise I don't think it must.
Thats why its gray. The program includes an info string which is a copyright notice, which is displayed by the system (Finder) in response to the Get Info for the application. Technically, its not displayed "by the program", but it is part of the program, and its a copyright notice, and its displayed as the program. But it's very small, not enough room for multiple copyright notices.
Well, I'm not familiar with MacOS issues, but I suppose there must be some kind of solution. What do others (free or non-free) do if there are multiple authors. (Though one hears a lot about Apple's "centralistic" approach, I don't suppose they allow only software with a single (entity as) copyright holder!?) Perhaps a pointer to a README or other file that contains detailed copyright statements?
Mind you, at least there is no equivalent to the OpenSSL press release debacle.
Which debacle?
They require two different notices to be included in any press release:
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. http://www.openssl.org/
This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)
Ah, well, that's the infamous "obnoxious BSD advertising clause" (see http://www.gnu.org/licenses/license-list.html#OriginalBSD). The original BSD license had introduced it. Meanwhille, after some lobbying by FSF and other groups, it was replaced by a license without this clause, for the Berkeley distribution and many other projects, but of course, there are still some with that clause around. It probably doesn't affect only OpenSSL.
Frank
-
Frank Heckenbach -
Peter N Lewis