On 2007-10-15, Jon L. [email protected] wrote:
Which one gives the user more freedom, the unconditional or
conditional grant?
The GPL gives the user complete freedom. It restricts other
activities, such as distributing a derived work, but it imposes no
restrictions on simply using the software.
Regards,
Jeremy H.
From: [email protected]
(Richard Stallman considers free licenses without copyleft
to be non-free.)
…With a license like the MIT (and BSD, and …) you give away your software
(almost) unconditionally…
…
With a license like the GPL, your software gift is conditional–the receiver
of the gift must (to use a phrase that I haven’t heard in this context
before) “pay it forward”.
Which one gives the user more freedom, the unconditional or conditional
grant?
That’s rhetorical. I’ve already determined the answer for myself.
While GPL software apparently does fall under the OSD , it does impose a
practical though not explicit discrimination against a particular field
of endeavor… selling software.
Chad P. wrote:
My understanding is that a gem distributed under the terms of the GPL
distribution. (Most of the commentary is written from the perspective
of C programmers, and doesn’t necessarily apply to Ruby programs.)Yes, but . . . it’s entirely possible that someone might want to ship a
bundled application. In such a circumstance, you’re probably trying to
make things convenient for an end-user that shouldn’t have to know
anything about, say, ruby gems. An installer that sticks everything in
place really changes the face of things for you in such a circumstance.
As I said, “Kind of fuzzy” isn’t the half of it.
So in the case you’re considering, what does the installer do? If it
downloads and installs the gem, then you aren’t distributing the gem.
OTOH, if you include the gem (perhaps to ensure that it’s the version
that you expect), then you are. It could go either way in different
circumstances. Some gems require that the version of the gem match
libraries installed on the system, in which case you had really better
not be distributing the gem, no matter what the license. Some don’t.
Actually, gems should probably be under the LGPL rather than the GPL for
just these reasons…but they may not be.
OTOH, if you’re distributing the code, why are you using gems, anyway?
Just distribute the source, and let your installer handle it. If you
distribute the source, you’re ALWAYS satisfying the GPL (unless you
obfuscate it or something).
But that said, there ARE corner cases. It’s fractally fuzzy.
On Oct 14, 2007, at 6:58 PM, Daniel DeLorme wrote:
M. Edward (Ed) Borasky wrote:
All this proves is that the distinction between the English
language and code is starting to erode, and when a programmer,
like Richard M. Stallman, dabbles in Law, it gets worse.Stallman is a coder? Didn’t know about that. What did he code?
emacs
Jeremy H. wrote:
On 2007-10-15, Jon L. wrote:
Which one gives the user more freedom, the unconditional or
conditional grant?The GPL gives the user complete freedom. It restricts other
activities, such as distributing a derived work, but it imposes no
restrictions on simply using the software.
Using that limited definition of user, one who “simply uses the
software”,
most proprietary licenses also give the user complete freedom.
On 2007-10-15, Jon L. [email protected] wrote:
Jeremy H. wrote:
The GPL gives the user complete freedom. It restricts other
activities, such as distributing a derived work, but it imposes no
restrictions on simply using the software.Using that limited definition of user, one who “simply uses the
software”, most proprietary licenses also give the user complete
freedom.
Including the freedom to install and run the software without paying
anything for it? I think not. And at my last office job I didn’t see
any proprietary software whose license did not restrict either the
number of installation hosts or the number (total or concurrent) of
users. GPL software has no such usage restrictions.
Regards,
Jeremy H.
John J. wrote:
emacs
And some other stuff – he’s been around a long time. I think he may
have even been involved in the creation of TECO. 
On Mon, Oct 15, 2007 at 11:46:50AM +0900, Charles D Hixson wrote:
downloads and installs the gem, then you aren’t distributing the gem.
OTOH, if you include the gem (perhaps to ensure that it’s the version
that you expect), then you are. It could go either way in different
circumstances. Some gems require that the version of the gem match
libraries installed on the system, in which case you had really better
not be distributing the gem, no matter what the license. Some don’t.
If I was shipping an app for non-technical end users so low down the DIY
scale that I’d automate installation of Ruby gems, I certainly wouldn’t
assume a broadband Internet connection during the installation process.
I’d also, as you suggested, want to make sure the version wouldn’t
change
and break the app.
Actually, gems should probably be under the LGPL rather than the GPL for
just these reasons…but they may not be.
OTOH, if you’re distributing the code, why are you using gems, anyway?
Just distribute the source, and let your installer handle it. If you
distribute the source, you’re ALWAYS satisfying the GPL (unless you
obfuscate it or something).
There are other potential issues than simply whether or not you satisfy
the source distribution requirements of the GPL.
But that said, there ARE corner cases. It’s fractally fuzzy.
Exactly.
On Mon, Oct 15, 2007 at 01:35:03PM +0900, Jeremy H. wrote:
freedom.
Including the freedom to install and run the software without paying
anything for it? I think not. And at my last office job I didn’t see
any proprietary software whose license did not restrict either the
number of installation hosts or the number (total or concurrent) of
users. GPL software has no such usage restrictions.
Considering we were talking about “freedom”, I didn’t think we were
talking about “free cost”.
The user does not necessarily get “complete freedom” (for instance, I’m
in the odd position of having a bunch of GPLed software on a shelf that
I
cannot legally give away for free, thanks to the rules relating to
upstream linking for GPLv2). Many of those cases are largely
unimportant, but the fact that restrictions still exist should not be
ignored.
I’m not saying there’s anything wrong with the GPL (nor that there
isn’t,
per se) at the moment. I’m just trying to stick to the cold, hard facts
of the matter. Considering ruby-talk isn’t exactly the proper venue for
an ideological war, I think we’d all appreciate it if you would do the
same rather than simply applying the blanket term Freedom to all things
GPL and defend it to your last breath – as you seem to be gearing up to
do.
Jeremy H. wrote:
anything for it? I think not. And at my last office job I didn’t see
any proprietary software whose license did not restrict either the
number of installation hosts or the number (total or concurrent) of
users. GPL software has no such usage restrictions.Regards,
Jeremy H.
Most proprietary end-user licenses explicitly forbid running the
software under a debugger, disassembling it, or benchmarking it and
publishing the timing results, even if you paid for it. It’s not just
distribution you can’t legally do.
On Sunday 14 October 2007 11:29 pm, Jon L. wrote:
Using that limited definition of user, one who “simply uses the software”,
most proprietary licenses also give the user complete freedom.
Hmm, most proprietary licenses (I can’t immediately think of any
exceptions)
do not give the user (who might be a programmer, or not) the freedoms
to:
(Phrased as above to stay away from the concepts of then distributing
those
changes to others, which most, I think, would not consider to be
(strictly)
user functions.)
Randy K.
On 2007-10-15, Chad P. [email protected] wrote:
software", most proprietary licenses also give the user complete
freedom.Including the freedom to install and run the software without paying
anything for it? I think not. And at my last office job I didn’t see
any proprietary software whose license did not restrict either the
number of installation hosts or the number (total or concurrent) of
users. GPL software has no such usage restrictions.Considering we were talking about “freedom”,
Chad, I was responding to someone’s direct reply to one of my
comments. It’s not relevant that you thought “we” were talking about
something else.
… I didn’t think we were talking about “free cost”.
The right to do some things for free is a pretty important freedom.
Or would you be happy having to pay $1000 to vote? Anyway, I
mentioned (and you conveniently ignored) several other freedoms. And
other posters have mentioned more.
The user does not necessarily get “complete freedom” (for instance,
I’m in the odd position of having a bunch of GPLed software on a
shelf that I cannot legally give away for free,
Irrelevant. My point was that usage is not restricted. And it
isn’t.
I’m just trying to stick to the cold, hard facts of the matter.
You most definitely are not, otherwise you would not have accused me
of:
… simply applying the blanket term Freedom to all things GPL and
defend it to your last breath – as you seem to be gearing up to do.
Why don’t you “stick to the cold, hard facts of the matter.” rather
than spreading rumours about what I “seem to be gearing up to do.”?
Meanwhile I’ll stick to defending what I actually said. Life’s too
short to waste time on other people’s silly fantasies about my
motives.
Regards,
Jeremy H.
On Tue, Oct 16, 2007 at 12:37:04AM +0900, Trans wrote:
Specific reasons are either:
1) I demand all derivative works also be OSS.
2) This software is mine mine mine (non-OSS or partial-OSS)
3) Another lib, that I must use, is forcing my hand.
3) Ruby license is not a good license to use, but unfortunately so
many Rubyists have used it we are kind of stuck with it --see 2.3
above. Thankfully, clause 4 of the license gets us out of point 2.1
(barely?).
I’m not quite as well-versed in the MIT license as I am in some others.
It is often compared with the BSD license as having similar terms,
however, so I’ll speak about the BSD license here (with which I’m more
familiar).
The BSD license actually provides for the code covered by the license to
be forevermore “open source”. There’s a common misconception that the
BSD license and similar licenses somehow allow you to make the code in
them proprietary. That’s not legally possible, as the BSD license
contains an inheritance clause that mandates further copies of the code
be distributed under the same license. The difference between that and
the voracious nature of the GPL is that the BSD license allows covered
code to be “wrapped” in code of another license, such that a complete
project can be distributed under the licensing terms of the copyright
holder’s choice while the specific parts of it that are licensed BSD
remain under the BSD license’s terms. The GPL demands that everything
that is connected to code it covers must also be distributed under its
terms.
So . . . the MIT license may very well be quite suitable to situations
where you “demand that all derivative works also be OSS”. That really
depends on how you mean that statement to be interpreted.
As for the flame war prone nature of license discussions, I guess I
probably should have left well enough alone rather than asking someone
to
keep his/her personal opinions down to a dull roar. The obvious pro-GPL
implications of a preceding message in this thread seemed to require
some
correction, and I made the mistake of not realizing attempting to cut
the
rhetoric away from the facts would be something like throwing fuel on a
fire. I apologize for that misjudgment.
On Mon, Oct 15, 2007 at 08:33:58PM +0900, Randy K. wrote:
Using that limited definition of user, one who “simply uses the software”,
most proprietary licenses also give the user complete freedom.Hmm, most proprietary licenses (I can’t immediately think of any exceptions)
do not give the user (who might be a programmer, or not) the freedoms to:
- review (and learn) from the source code
- modify the program (using the source code) for his own purposes and use
- pay someone other than the original “manufacturer” to modify the program
for his own purposes and use
I’d classify the first two (because they specify access to source code
as
a condition, rather than referring to any legal privilege) as
“capability” or “opportunity” rather than “freedom”. I’m a stickler for
terms that way.
On Oct 15, 7:55 am, Jeremy H. [email protected] wrote:
activities, such as distributing a derived work, but it imposes no
users. GPL software has no such usage restrictions.
Or would you be happy having to pay $1000 to vote? Anyway, I
I’m just trying to stick to the cold, hard facts of the matter.
short to waste time on other people’s silly fantasies about my
motives.
Uh oh. We were doing so well! A potentially flaming subject kept to a
congenial ember.
Tell you what. Lets now take a different bent: Here is what I think I
learned from this thread.
T.
On 15/10/2007, Chad P. [email protected] wrote:
holder’s choice while the specific parts of it that are licensed BSD
remain under the BSD license’s terms. The GPL demands that everything
that is connected to code it covers must also be distributed under its
terms.So . . . the MIT license may very well be quite suitable to situations
where you “demand that all derivative works also be OSS”. That really
depends on how you mean that statement to be interpreted.
The major difference from the “forever opensource” point of view is
that BSD license does not require you to distribute the code in source
form.
This allows you to only distribute the binaries of a modified version
of the software and keep the source, making the software as
proprietary as it ever gets. People can disassemble it, but they can
do the same with proprietary software (the license may forbid it but
it is unenforcible technically and often even legally). To disallow
copying the binaries just link with a proprietary module.
Thanks
Michal
On Tue, Oct 16, 2007 at 02:36:42AM +0900, Michal S. wrote:
The major difference from the “forever opensource” point of view is
that BSD license does not require you to distribute the code in source
form.
This allows you to only distribute the binaries of a modified version
of the software and keep the source, making the software as
proprietary as it ever gets. People can disassemble it, but they can
do the same with proprietary software (the license may forbid it but
it is unenforcible technically and often even legally). To disallow
copying the binaries just link with a proprietary module.
Software gets a lot more proprietary than “only available as a
binary”.
It’s also rather difficult to get existing copies of source out of
circulation, so taking a copy of the publicly available source and
compiling it, then distributing only the binary, doesn’t really
accomplish much in terms of making it more “closed”, in practice.
Your comment about what is and is not enforceable strikes me as
premature
and lacking strong supporting evidence.
On Oct 15, 9:20 am, Chad P. [email protected] wrote:
one like MIT.
Specific reasons are either:
1) I demand all derivative works also be OSS.
2) This software is mine mine mine (non-OSS or partial-OSS)
3) Another lib, that I must use, is forcing my hand.
3) Ruby license is not a good license to use, but unfortunately so
many Rubyists have used it we are kind of stuck with it --see 2.3
above. Thankfully, clause 4 of the license gets us out of point 2.1
(barely?).
be distributed under the same license. The difference between that and
the voracious nature of the GPL is that the BSD license allows covered
code to be “wrapped” in code of another license, such that a complete
project can be distributed under the licensing terms of the copyright
holder’s choice while the specific parts of it that are licensed BSD
remain under the BSD license’s terms. The GPL demands that everything
that is connected to code it covers must also be distributed under its
terms.
That’s good to understand.
So . . . the MIT license may very well be quite suitable to situations
where you “demand that all derivative works also be OSS”.
Does it? I thought it was just the opposite.
That really
depends on how you mean that statement to be interpreted.
Well, I was thinking “GPL” in this case.
As for the flame war prone nature of license discussions, I guess I
probably should have left well enough alone rather than asking someone to
keep his/her personal opinions down to a dull roar. The obvious pro-GPL
implications of a preceding message in this thread seemed to require some
correction, and I made the mistake of not realizing attempting to cut the
rhetoric away from the facts would be something like throwing fuel on a
fire. I apologize for that misjudgment.
Well, we are all entitled (even to argue if we want But classically
I think the “war” of license is between GPL and BSD isn’t it? That’s
probably a huge over simplification, but that tends to be my shallow
assessment of the field. And that was really the crux of my dividing
line for point 2.1.
T.
On 15/10/2007, Chad P. [email protected] wrote:
copying the binaries just link with a proprietary module.
Software gets a lot more proprietary than “only available as a binary”.
It’s also rather difficult to get existing copies of source out of
circulation, so taking a copy of the publicly available source and
compiling it, then distributing only the binary, doesn’t really
accomplish much in terms of making it more “closed”, in practice.
Please, read what you are responding to. The critical part is you
modify it. Then the modification is only available as part of you
proprietary product which you make as proprietary as you like.
Your comment about what is and is not enforceable strikes me as premature
and lacking strong supporting evidence.
Whatever. But unless you also require a separate hardware, physical
security, and whatnot, it is possible to disassemble the software, and
in practice this option is used.
Thanks
Michal
On Tue, Oct 16, 2007 at 02:59:05AM +0900, Trans wrote:
Well, we are all entitled (even to argue if we want
I think the “war” of license is between GPL and BSD isn’t it? That’s
probably a huge over simplification, but that tends to be my shallow
assessment of the field. And that was really the crux of my dividing
line for point 2.1.
Actually, from the FSF point of view (what one might call “copyleft”),
it’s basically “GPL vs. everyone else”. From the proprietary point of
view (what one might call “copyright”), it’s basically “proprietary vs.
everyone else, especially the GPL”. From the permissive licensing point
of view (what one might call “copyfree”[1]) – including the BSD
license,
among others – it’s basically “leave me the hell alone”.
Again, it’s a bit of a gross simplification, but I think it covers the
major views in those three “camps” (where “proprietary” is only a “camp”
in the same way Iraq, Iran, and Korea might be called an “axis of evil”,
which is to say “it’s not really a camp”, and where “permissive” is only
a “camp” in that it’s not part of either of the other two, and not only
isn’t really a camp but is just a bunch of individuals and small groups
who have something in common).
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs