Re: Is libreludedb DFSG compliant?
Josh Triplett wrote:
Marco Franzen wrote:
Josh Triplett wrote:
Mickael Profeta wrote:
If you link LibPreludeDB against other code all of which is itself
^^^
licensed under the terms of the GNU General Public License version 2
dated June 1991 ("GPL v2") or compatible, then you may use LibpreludeDB
under the terms of the GPL v2,as appearing in the file COPYING.
^
This looks fine to me.
What if I don't want to link it? I may want to [...]
With the above I have no license to do any of that. I am not even
sure I am allowed to make a private copy (jurisdiction dependency?).
Hmmm. When I read this statement, I interpreted "link" broadly here, in
the sense which includes combinations with other code that do not
necessarily involve invoking a linker.
When I hear someone talking about the GNU GPL, compatible licences
and linking, I expect them to talk about differences between it and the
GNU LGPL, about shared libraries and so on.
> Furthermore, I read it not as
"you must link it with GPL or compatible software in order to be used
under this license", but as "for all software linked to it, that
software must be GPL or compatible", making it still vacuously true that
the software is GPL if linked with nothing else.
That may well be what they mean, but it is not what they say. (That is
probably just a bug in the grant.)
Thus, the statement
seemed compatible with (and redundant given) the GPL.
Yes, likely they mean just to restate parts of (what they think)
the GNU GPLv2 itself says or means.
In that case they should not refuse to just grant the GNU GPLv2
directly. If they did refuse then that would be suspicious.
> If either of
those two assumptions was not the intended reading of the statement,
then I agree entirely with your argument that the statment renders the
software non-free. In any case, yes, the simplest solution is to avoid
making such explanations in a form that makes them look like additional
conditions of the license.
- Josh Triplett
Probably neither "linking" nor "compatible" has a clear enough meaning
to be used without further explanation in a meaningful licence grant.
Let's hope they'll adopt the standard boilerplate (ideally also avoiding
mentioning the name of the software in the grant as the last minor nit).
--
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
Ken Arromdee wrote: On Wed, 4 Jan 2006, Marco Franzen wrote: What if I don't want to link it? I may want to - just publish (parts of) the source code (or (of) a modified version) - modify it into something that isn't a library and publish the source - paste code fragments into an embedded/free-standing application (which does not link against anything, not even libc), maybe with some modifications to fit the new environment - copy code fragments into documentation Couldn't you just link it with something, putting it under the terms of the GPL, then unlink it, whereupon it's still under the terms of the GPL, then use it as above? As I tried to say two paragraphs later, in order to link it it needs to compile first, and you cannot make changes to get it to compile before you have a license. OK, if you are lucky and it compiles for you without changes, you could take the GNU GPLv2 grant for your throw-away linking, remove the trigger condition and re-publish it under plain GNU GPLv2 for the rest of the world. However, there would still be some risk that they (or their successor in copyright) sue you for violation of their copyright, claiming that their "If" meant "As long" rather than "Once". That it was not a trigger for a GNU GPLv2 grant but a grant of a modified license, namely the licence that results when you add their linking condition to the GNU GPLv2. This "so-modified-GPL" would not only be GNU-GPLv2 incompatible, but with this particular condition (IMHO) non-free: 1. It would /require/ linking against /some/ other code that is licensed both GNU-GPLv2 compatibly (to satisfy the added restriction) and so-modified-GPLv2 compatibly (so /its/ licensing allows this linking - the GNU GPLv2 itself does not). 2. It would /forbid/ linking against /any/ code that is /not/ licensed both GNU-GPLv2 compatibly and so-modified-GPL compatibly. The code linked against could for example be dually licensed GNU GPLv2 and so-modified GPL, or it could be under a single liberal licence. (Each of these two requirements would be non-free, IMHO. Having to link, as argued in the quoted paragraph. Having to licence your contributions more liberally than the original software would fail DFSG#3.) But I doubt they really mean any of that silliness. It might be possible to convince them to give a simple GNU GPLv2 grant. It might actually be what they meant to do in the first place. Some clarification seems necessary in any case. -- Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is libreludedb DFSG compliant?
Josh Triplett wrote:
Mickael Profeta wrote:
If you link LibPreludeDB against other code all of which is itself
^^^
licensed under the terms of the GNU General Public License version 2
dated June 1991 ("GPL v2") or compatible, then you may use LibpreludeDB
under the terms of the GPL v2,as appearing in the file COPYING. If the
^
file COPYING is missing, you can obtain a copy of the GPL v2 from the
Free Software Foundation Inc., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301, USA.
This looks fine to me.
What if I don't want to link it? I may want to
- just publish (parts of) the source code (or (of) a modified version)
- modify it into something that isn't a library and publish the source
- paste code fragments into an embedded/free-standing application
(which does not link against anything, not even libc),
maybe with some modifications to fit the new environment
- copy code fragments into documentation
With the above I have no license to do any of that. I am not even
sure I am allowed to make a private copy (jurisdiction dependency?).
This may not look like a freeness issue because one could always do
some trivial linking first to get the GPL grant. But if the code does
not compile on any system available to me, then I have no licence to
change it into something that I can compile and link...
I think what the licensor really means is to license it under the GPL,
so they should do just that rather than trying to paraphrase the GPL
in one sentence or trying to grant the GPL licence conditionally
or whatever it is they are trying there.
I think they just mean to say that the GPL is not the LGPL. If they feel
they really need to say that, they can do so outside the formal licence
grant: use the standard "This is free software..." boilerplate and then
add something not legally binding, like "Note that the GNU GPL requires
you..." if they must. Although I'd prefer they didn't.
--
Marco
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL "or any greater version"
Raul Miller wrote [in reply to Michael Poole]: You seem to be claiming that the GPL implicitly allows the constraint "no future versions of the GPL may be used" as if that constraint were written into the license (see section 8 for an explicit example of this kind of language). That is not a constraint on the licence, it *is* the licence. The licence is just what is detailed in a particular version of the licence text. Different versions are different licences. Since these licences all have the same name, a licensor would normally have to specify the version in addition to the name in order to make a meaningful grant (or at least there might be some doubt). Section 9 of GPLv2 clarifies how that licence *can* co-exist with a (potentially infinite) number of further licences also granted (most of which have not yet been written) *if* the grant is worded in certain ways. -- Marco
Re: NEW ocaml licence proposal by upstream, will be part of the 3.08.1 release going into sarge.
Raul Miller wrote: On Thu, Aug 26, 2004 at 02:19:23PM +0100, Steve McIntyre wrote: This excerpt is quite clear: A Program may specify GPL2 and "any later version" - check If the Program just says "GPL", the recipient may use any version - check If the Program says "GPL v2" alone, there's nothing in S9 that leads to later versions being applicable. I can see why you'd think that. However, that's not one of the terms offered by GPL v2. It actually is, even explicitly. Section 0: | 0. This License applies to any program or other work which contains | a notice placed by the copyright holder saying it may be distributed | under the terms of this General Public License. It does not say "or any later version" here, and "this General Public License" is of course this GPL v2. So in section 0, GPL v2 declares itself applicable to works that contain a notice saying it is. In section 9, GPL v2 declares itself joint applicable, in the sense of a dual, triple, ... licence, if the notice uses the given language, for example says "v1 or (at your option) any later version" or does not mention a version. As usual, someone receiving a work under multiple licences can just disregard any of them. If you accept GPL v2, you can modify the work under section 2. 2(b) does not require you to preserve the notice: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. That would still be satisfied if you changed the notice from This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. to This program is free software; you can redistribute it and/or modify it under the terms version 2 of the GNU General Public License as published by the Free Software Foundation. -- Marco
Re: oaklisp: contains 500kB binary in source
Barak Pearlmutter wrote: source package; the source includes a interpreter and it would be a relatively small matter to translate it from Oaklisp into RnRS Scheme. Correct me if I am wrong, but AIUI if someone wants to package a GPLed Java program that, as it is, currently runs only on a non-free VM, then even its source package is (at most) contrib. Even if everyone agrees that it would be a small matter to port it to a free VM, this is no consideration until someone actually does so. The only difference I can see here is that you might claim that Oaklisp is already free. But that argument would be circular until someone actually does what you say is possible. All source is available: if you have any doubts at all you are ideally situated to verify the system's integrity. All source may be available or not; this is hard to tell until someone actually tries what you say is possible. Bootstrapping might fail because an Oaklisp-specific feature of the target system is subtly implemented by the same feature in the host system, accidentally or not. Stepping back a bit, maybe the question is, which side has the burden of proof? The side arguing something is (or might be) free or the side arguing something is not (or might not be)? In the case of Java programs, main contains only what is free, not what might be free. (Again, kindly correct me if I am wrong.) Cheers, Marco
Re: oaklisp: contains 500kB binary in source
Walter Landry wrote: Marco Franzen <[EMAIL PROTECTED]> wrote: Barak Pearlmutter wrote: This is a technical issue related to ease of bootstrapping on a new architecture, and not a legal issue. It may not be a legal issue, but I think it is more than merely technical. It does touch the freeness question. We can reproduce the executable, and we can make modifications to create a new executable. Free software does not mean that the compilers used to create executables are free from bugs, malicious or not. But it requires (among other things) that you have full source code. Ken Thompson's article is just about a particularly devious way of hiding a bug. It doesn't make the bug immune from detection, just a heck of a lot more difficult. Ken Thompson demonstrated a technique to piggy-back a malicious routine into a bootstrap binary so it propagates into binaries created by it without being present in its apparent source. More generally it is a technique to hide source code from you, without you even being aware of it. It can be used not only to piggy-back malicious extra-functionality but also (if that convinces you more) to hide parts of the payload functionality. You could (not very subtly) provide a dump_compiler primitive in your language dialect, so your compiler source could be completely absent. Or you could just hide a proprietary subsystem for, say garbage collection. How do you know you have (all) the source for the functionality that you actually want, short of reading and understanding all the source and how it all fits together? Of course, in the end of the day, this is all about trust. A malicious person could become a DD and do all sorts of bad things until they are found out. Should it be a judgement call by the packager (guided by how well they know upstream, how well they understand the code, etc)? Marco
Re: oaklisp: contains 500kB binary in source
[Sorry about the long lines in my earlier post, thanks for wrapping them, Raul.] Raul Miller wrote: On Sun, Jun 13, 2004 at 04:17:29PM +0100, Marco Franzen wrote: To understand what I mean, you may want to read Ken Thompson's old article[0] on how to hide a Trojan Horse in a compiler without it being present in its "source" at all - just provided you bootstrap it with a given binary that already contains the Trojan Horse. Unless/until it can be proved that the binary's behaviour is acurately described by its (alleged) source, it is unclear whether its (true) source is provided or missing. Erring on the side of caution, it would need to be ruled non-free. The source (with the bootstrap binary removed) could therefore be at most contrib. How is this different from glibc? Technically, you don't need a glibc binary to produce a glibc binary. You can produce it on existing platforms (free and non-free ones) that do not use glibc (and in whose ancestorship glibc was never used). Ok, I'm told it's possible to build glibc under bsd's libc, but are we doing that? It does not need to be done on each build. The freeness issue goes away (together with the related potential security problem), once it is established that the alleged source is truely the source, in the sense that it accurately describes the behaviour of the binary. (The proof could even be allowed to use non-free tools where we can trust them, and if it's only for a proof.) If oaklisp's binary can be built under some other lisp implementation, is that sufficient? If an unrelated (and "trustworthy") lisp implementation produced the same binary, then that would certainly be proof enough (possibly even if the other lisp implementation was not free). Alternatively, if the binary was produced by another lisp implementation that has already been (correctly) proved to be free, that would also be fine. If producing the binary requires lots of arcane features that are not present in any other lisp implementation, then, until an acceptable bootstrap path is shown, that is a problem - for both freeness and security. What does "bootstrap from scratch" mean? I mean an "acceptable" bootstrap path. As Florian said earlier, it needs to be decided on a case-by-case basis - with [0] in mind. > Is it more important for oaklisp than glibc? It is important for both. I could turn it around: If glibc binaries really had virus that were not it its source, and if that could have been avoided by more painful bootstrapping, would that mean clean oaklisp bootstrapping should not be required? (Of course oaklisp would be the least of our problems then.) [You snipped this, probably because it was in .sig position:] >>[0] http://www.acm.org/classics/sep95/ Marco
Re: Draft Summary: MPL is not DFSG free
Bernhard R. Link wrote:
* Andreas Barth <[EMAIL PROTECTED]> [040613 13:16]:
Not true at all. The GPL, for example, is not a valid contract.
Neither is the MIT/X11 license.
Please abstract from your own legal system. In some legal systems, the
GPL or the MIT/X11 license is a contract, in others not.
Only in the sense that the German system has a contract as most basic
operation of law, while other system (especially those where the word
contract is actually used) have a contract as relatively high contruct
and distinguish between contracts and non-contracts.
IANAL, but I think you are mixing up "Vertrag" (contract) und
"Willenserklaerung" (expression/declaration of will/intent) here, which
is more basic.
As I understand German law, a contract between N parties is formed
simply by each of them uttering agreeing declarations of intent. In the
simple case of two parties, the declaration first uttered is called
application or offer ("Antrag" or "Angebot"), the second one acceptance
("Annahme").
These utterances can take different forms. They can, for example, be
written and signed (possibly in front of a notary pulic), just spoken,
or merely implied by conclusive action. (Depending on the contract
matter, the law may prescribe certain forms, though.)
Given the right context, a simple dialog like "Please have a sandwich!",
"Yes, thanks!" can form a contract, as can the simple giving and taking
of the sandwich, or a mix of the forms. (Depending on the intentions on
the parties, the sandwich could have been gifted or sold.)
A public licence like the GPL is then the offer (or application) to form
a two-party contract, extended to everybody. Anybody can then accept the
offer/application and thus conclude a separate two-party contract with
the licensor. Conclusive action implying acceptance could indeed be the
redistributing of the software. A contract would not have been formed
(but also not be necessary) until some suitable action on the part of
the licensee at least implies acceptance.
What is special about the public license is that it is a true offer
(binding on the licensor). Normal public advertising, although commonly
called offer, would not be an actual (binding) offer in the legal sense,
but just be an invitation for applications ("freibleibendes Angebot").
Apparently the systems in continental Europe are all similar, but the
Anglo-Saxon system is different.
Marco
Re: oaklisp: contains 500kB binary in source
Barak Pearlmutter wrote: This is a technical issue related to ease of bootstrapping on a new architecture, and not a legal issue. As a technical measure, the circular dependency could be broken and the alternative prebuild-world-in-source kludge eliminated by writing an Oaklisp interpreter in another language (say, RnRS Scheme, or Haskell) for invocation when an already-built Oaklisp is not available on the build platform. I'm absolutely positive the upstream maintainer would welcome any such patch. But, this has nothing to do with the legal status of the package. It may not be a legal issue, but I think it is more than merely technical. It does touch the freeness question. It is about trust that the source provided is actually the true and full source for the given binary. This is not proven just because the source compiled with the binary reproduces the binary (even if it does). To understand what I mean, you may want to read Ken Thompson's old article[0] on how to hide a Trojan Horse in a compiler without it being present in its "source" at all - just provided you bootstrap it with a given binary that already contains the Trojan Horse. Now just consider the *possibility* that the upstream bootstrap binary *might* contain such a self-reproducing Trojan Horse. One important aspect of Free Software is that you have (at least in principle) full control over what your computer does. It is your computer, not the s/w manufacturer's. Unless/until a clean and free bootstrap from scratch is available, it seems to me the source (with the bootstrap binary removed) may be contrib, but the binary could only be non-free. Unless/until it can be proved that the binary's behaviour is acurately described by its (alleged) source, it is unclear whether its (true) source is provided or missing. Erring on the side of caution, it would need to be ruled non-free. The source (with the bootstrap binary removed) could therefore be at most contrib. Marco [0] http://www.acm.org/classics/sep95/
Re: ipw2100 firmware distributable?
Raul Miller wrote: On Mon, May 31, 2004 at 06:47:01PM +0100, Marco Franzen wrote: Right: If something needs special permission, it is non-free and can at most go into non-free. But since non-free is not part of debian (the distribution), special permission only for distributing it *in* debian would be useless in any case. (But that is likely not what was meant.) Something can be in debian archives which are not a part of a debian distribution. For example, the bts, mailing list archives (including debian-private which isn't publically accessible), and so on. Sure. But it would depend on what the special permission "to distribute [it] in debian" were later construed to have meant. It does sound very much like "to put [it] in the debian distribution". I thought this might be a potential lawyer bomb that could be avoided easily by wording the request for permission slightly differently. Nobody would be likely to sue for this reason, but someone looking for a reason to sue (tentacles of evil etc) might just be happy to find one. Marco
Re: ipw2100 firmware distributable?
Mahesh T. Pai wrote: Sebastian Ley said on Mon, May 31, 2004 at 02:11:22PM +0200,: > If they refuse to change or clarify the license, what would you > think of getting a special permission for distributing it in > debian? They have given it before (see my first post). What would I > have to take care of? Cannot be included, not even in non-free, IMHO. Will violate DFSG #8. Right: If something needs special permission, it is non-free and can at most go into non-free. But since non-free is not part of debian (the distribution), special permission only for distributing it *in* debian would be useless in any case. (But that is likely not what was meant.) An alternative licence (if need be, specific to debian (the project) and its mirrors) to distribute and re-distribute, without confidentiality and export restriction clauses, may allow it into non-free (depending on the concrete licence). For simplicity (and reduced non-freeness), they might as well grant a public licence to everybody to distribute "as-is". IANAL, IANADD, IJRDL, *and* I am new to this list... -- Marco
[OT] "is really" (Was: Re: Patent issues)
> G. Branden Robinson| Psychology is really biology. > Debian GNU/Linux | Biology is really chemistry. > [EMAIL PROTECTED] | Chemistry is really physics. > http://people.debian.org/~branden/ | Physics is really math. ;-) But then: Math is really philosophy. Philosophy is really psychology.
