Mark Rafn wrote:
[ ... ]
Does OSD #3 mean that "The license must allow [ALL] modifications and derived
works, ...", without any restrictions?
IMO, pretty much yes.
Hmm. I agree that users of open source software generally should have the right
to fork and distribute modifications of software, e
on Wed, Jun 18, 2003 at 05:13:26PM -0400, Forrest J. Cavalier III ([EMAIL PROTECTED])
wrote:
> Mark Rafn <[EMAIL PROTECTED]> wrote, in part:
>
> > It doesn't even seem close to me. Let me know if I'm insane, or reading
> > it wrong, but I can't see how such a restriction can be considered open
David Presotto wrote:
[ ... ]
I understand where someone wouldn't want their code destroyed, perverted,
whatever. However, broken or malicious is a bit of a judgement call, is
it not? I have a hard time seeing where the line would be drawn.
I agree with you that it's hard to draw the line exactly
On Sun, 22 Jun 2003, Chuck Swiger wrote:
> [ ...I haven't seen this message appear on the list; resend... ]
>
> Mark Rafn wrote:
> > It may not be pertinent to the licensor's need. I very much hope it is
> > pertinent to OSI's need to restrict use of it's service mark only to
> > software whic
On Sun Jun 22 15:40:06 EDT 2003, [EMAIL PROTECTED] wrote:
> [ ...I haven't seen this message appear on the list; resend... ]
>
> Mark Rafn wrote:
> > It may not be pertinent to the licensor's need. I very much hope it is
> > pertinent to OSI's need to restrict use of it's service mark only to
>
[ ...I haven't seen this message appear on the list; resend... ]
Mark Rafn wrote:
It may not be pertinent to the licensor's need. I very much hope it is
pertinent to OSI's need to restrict use of it's service mark only to
software which can be freely modified.
Does OSD #3 mean that "The license
On Fri, 20 Jun 2003, Rod Dixon, J.D., LL.M. wrote:
> It has come to my attention off-list that I may need to clarify my comment
> on the proposed RSPL.
This is somewhat academic for me, since the RPSL has been amended to allow
distribution under the almost-GPL. I'm still curious about this line
It has come to my attention off-list that I may need to clarify my comment
on the proposed RSPL.
I made 3 observations; namely, that since [1] section 2a of the proposed
license is identical to section 2a of the GNU LGPL; [2] the proposed license
has a similar purpose as the GNU LGPL (according
> Only if their fork is still a software library. Nobody can fork it to
> become an application.
I'm not sure how your problem is actually a restriction. Suppose, I
as a developer wish to distriibute at application the uses the library
in question. To distribute my application, I simply distri
Hello Mark,
would you be satisfied if we added a clause that looked something like:
At your discretion, you may apply the terms of the ordinary GNU GPL (as
published by the FSF) to your modified copy of the Library, and copy and
distribute such work under the terms of the GNU GPL, provided that yo
On Thu, 19 Jun 2003, Rod Dixon wrote:
> I think there are two issues here: [1] the section 2a requirement that
> limits the rights granted to the public distribution of libraries and [2]
> the licensor's intent to permit dynamic linking of the open source library
> with non-free software. If this
On Wed, 18 Jun 2003, Christophe Dupre wrote:
> Hello Mark,
> I've just re-read the OSD document, and I'm not sure we read the same
> one. You claim that 2a and 2d are unacceptable and violate OSD#3.
> OSD#3 is not violated: you can change the code, you can distribute those
> modifications. #3 do
I think there are two issues here: [1] the section 2a requirement that
limits the rights granted to the public distribution of libraries and [2]
the licensor's intent to permit dynamic linking of the open source library
with non-free software. If this is correct, then section 3 of the LGPL,
which s
On Wed, 18 Jun 2003, Rod Dixon, J.D., LL.M. wrote:
> : Am I the only one who thinks 2a and 2d are unacceptible? It violates
> : OSD#3 by limiting the type of derived work,
> I think you have to evaluate the license in the context of what the author
> has told us about his purpose.
I at least pa
Hello Mark,
I've just re-read the OSD document, and I'm not sure we read the same
one. You claim that 2a and 2d are unacceptable and violate OSD#3.
OSD#3 is not violated: you can change the code, you can distribute those
modifications. #3 doesn't say that it needs to be completely
unrestricted.
:
: Am I the only one who thinks 2a and 2d are unacceptible? It violates
: OSD#3 by limiting the type of derived work,
I think you have to evaluate the license in the context of what the author
has told us about his purpose. The GNU LGPL, for example, makes more sense
when you consider its purpos
Mark Rafn <[EMAIL PROTECTED]> wrote, in part:
> It doesn't even seem close to me. Let me know if I'm insane, or reading
> it wrong, but I can't see how such a restriction can be considered open
> source.
>
> I know they're straight from the LGPL, but they are irrelevant there
> because the LGP
Mark Rafn wrote:
On Wed, 18 Jun 2003, Rod Dixon wrote:
[ ... ]
Am I the only one who thinks 2a and 2d are unacceptible? It violates
OSD#3 by limiting the type of derived work, perhaps OSD#6 by limiting
itself to creators of software libraries, and perhaps OSD#8 by being
specific to the product "so
I'm unsure at this time about your comments regarding OSD#6 and 8, but one
thing seems clear to me: one can distribute an application that's
statically link with the library. Such an application would be a 'work
that uses the library', and the only limitation with a binary linked with
library is th
On Wed, 18 Jun 2003, Rod Dixon wrote:
> This version seems fine, given what we were told about the license last
> time. I read this license to have the same or similar purpose as the LGPL,
> and in that respect section 2(a) seems permissible. It is a slight
> restriction that could have a strategi
This version seems fine, given what we were told about the license last
time. I read this license to have the same or similar purpose as the LGPL,
and in that respect section 2(a) seems permissible. It is a slight
restriction that could have a strategic purpose, but the author says the
limitation i
On Wed, 18 Jun 2003, Christophe Dupre wrote:
> Cluase #2 was changed, and doesn't ask for automatic co-ownership of
> changes, but only those submitted for inclusion in central repository.
> Would this be more palatable to this group ?
> Is there any additional objection ?
Thank you, I think this
> b) Accompany it with a written offer, valid for at least three tears, to
> give any third party, at no charge, a complete machine-readable copy of
> the corresponding source code, to be distributed under the terms of
> Sections 1 and 2 above on a medium customarily used for software
>
Well, are
Following all the comments received from this list about a week ago, we've
slightly modified the license. It now stands as follows.
Cluase #2 was changed, and doesn't ask for automatic co-ownership of
changes, but only those submitted for inclusion in central repository.
Would this be more palatab
24 matches
Mail list logo
