emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: enable MELPA & Marmalade by defaul [was: mykie.el]


From: Drew Adams
Subject: RE: enable MELPA & Marmalade by defaul [was: mykie.el]
Date: Tue, 7 Jan 2014 09:44:01 -0800 (PST)

Hi Grim,

> > Putting them in the available-by-default list does *not*
> > recommend them, IMO.  And it is certainly possible for GNU
> > Emacs to post a big banner saying that the ONLY repository
> > it recommends is its own ELPA repository, genuine GNU ELPA.
> > Nothing wrong with that.  Would that satisfy your
> > recommendation worry?
> 
> A reluctant endorsement is still an endorsement.

Where do you see an endorsement in that - reluctant or enthusiastic?

> > And anyway, nothing says that those repositories involve much
> > non-free software, or even any at all.
> 
> I viewed a random package in Marmalade and it had no indication
> of a license whatsoever.

How many times did you pick a "random" package?  Once?
What proportion of Marmalade packages have no license?

> Perhaps the author intended to release it as free software or
> could easily be convinced to do so, but as it stands now,
> Marmalade is not completely free software.

I never claimed that either MELPA or Marmalade is completely
free software.  Is there some free software there?  Is it useful?

> > Without looking, I'd bet that the *overwhelming mass* of packages
> > in those two repositories are free software (GPL'd).  Why make
> > users jump through extra hoops to access all that free software,
> > even if there might also be a non-free package there somewhere?
> >
> > Do you think that a downloading user cannot tell whether some
> > software is free or not?  If so, is this about trying to hide
> > that non-free software from their unsuspecting hands, so they
> > cannot make the awful mistake of not recognizing it?
> 
> It seems like a reasonable assumption that the overwhelming mass is
> licensed under the GPL, but I absolutely do think a user cannot tell
> whether an unlabelled package is free or not, at least I can't, not
> without consulting the author.

I'm no expert on package.el.  But perhaps it is a current limitation
if it does not either (a) provide a command that shows the license
(e.g., by searching the file header) or (b) let you easily browse
(at least) the main file of the package (which presumably has a
license) before downloading (or perhaps before installing).

IOW, I agree that it would be good for a user to be able to see
such info before hand, while browsing the repository.  Likewise,
to see the name of the author/maintainer.  Whether that is a
(missing) package.el feature or a (missing) repository feature,
I don't know.

> > If so, that kind of protection-by-ignorance is doomed to be
> > ineffective and even counterproductive in the long run, IMHO.
> >
> >> RMS and his defense of the FSF position (and composure in
> >> the face of very shabby treatment) are remarkable.
> >
> > Agreed 100%.  And so?  Has RMS said that listing those two
> > repositories would hurt free software?  Maybe a lawyer from
> > the FSF will chime in.  (As if we didn't get enough
> > software-development-by-legal-department these days..., but
> > I digress.)
> 
> You're suggesting it's a legal issue. I don't see how it is. It's
> not illegal to recommend non-free software.

Please read what I wrote.  Did I say anything about illegality?

I'm not suggesting that.  I'm suggesting that perhaps RMS or FSF
would not want to list those repos by default because of legal
considerations.  And "legal considerations" does not mean that
something is illegal.  Most commonly these days, it means "for
fear of a lawsuit", but it can also mean, "just to avoid any
possible legal problems."

But mainly I was saying that, so far, RMS and FSF have not
said anything about this.  They have not chimed in with any
objection.  This was in response to statements that presumably
this would go against software freedom.  If it does, then I
am sure we should hear from RMS/FSF soon enough about that.

> > How about my Samsung - Netflix analogy?  Do you think you'd
> > stand a chance if you sued Samsung because one of Netflix's
> > films offended you?  Is Samsung liable for bad Netflix films
> > because it makes Netflix available by default on your new TV?
> 
> As far as I know it's not illegal to include Netflix in your
> products either.

It really sounds like you are confusing law, which includes
civil and criminal law, with criminal law.  I spoke about law
suits, not illegality.

> It's a social problem, not a legal one, and yes, Samsung
> should be held responsible for it. 

Good luck with a law suit on that basis.

> If they were distributing Busybox without the source, that
> would be both a social and a legal issue.

Irrelevant.  No one is saying anything about distributing
GPL software (or any software) without the source code.  You
are off the mark here.

> > I think you are really exaggerating there (but I am not a lawyer).
> >
> > That sounds very much like the kind of thing one sometimes hears
> > in commercial companies about GNU (!) and why GNU software should
> > be avoided like the plague by companies because it supposedly
> > sucks all of the company's own software into a free-software
> > tainted purgatory.  Dueling bogeymen.
> 
> Although unrelated to the current discussion, Bradley Kuhn does a
> good job explaining why some companies oppose copyleft software
> of which they are not sole copyright holders:
> http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

Thanks for the info; interesting.

Regards,

  Drew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]