Re: [HACKERS] Readline use in trouble?
От | Brook Milligan |
---|---|
Тема | Re: [HACKERS] Readline use in trouble? |
Дата | |
Msg-id | 199910201537.JAA15081@biology.nmsu.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Readline use in trouble? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Readline use in trouble?
|
Список | pgsql-hackers |
Good question. The GPL contains a clause to the effect that "mere aggregation" of a GPL'd piece of code in a sourcedistribution with unrelated pieces of code is OK, even if those other pieces of code are not GPL'd. But the contribdirectory is not exactly unrelated to the main Postgres distribution, so I'm not sure that we can point to thisclause to justify putting a GPL'd program in contrib. It'd be a gray area... The problem only comes if I, for example, want to distribute all of postgresql (contrib included) in a non-source (i.e., proprietary) way. That is fine if contrib includes no GPL code; if it does, I need to distribute the code for that portion only. Thus, if we want to maintain as broad a potential as possible (including non-source distributions) we need to encourage adoption of the BSD license for all source. To make it easier for those distributing postgresql to keep track of this stuff, perhaps we need a gnu (or gpl) directory (like or under contrib) in which would go GPL code. Then it would be crystal clear which portion of the code has which restrictions. It would also be clear that this is an aggregation. This is the mechanism used by NetBSD for their code tree, which does include some gnu software. Still, encouraging non-GPL contrib stuff is a good thing in order to maintain future options, because GPL contrib code _cannot_ be added to the main tree without affecting the distribution of the entire thing. Cheers, Brook
В списке pgsql-hackers по дате отправления: