License survey

License survey

[Rich Felker]

Hey everyone,

Lately there's been a lot of discussion on IRC about license issues,
starting with Rob Landley's diatribe about acceptance on Android
systems, and subsequent conversations on similar topics. While musl is
almost entirely code I've written and I'm not prepared to make any
immediate changes, I'd like to hear from anyone in the community
that's built up so far around musl as to what your views on licensing
are and whether you'd want to see any changes in how musl is licensed.
Some questions to think about:


Which is more important, copyleft or widespread usage of musl?

Which copyleft issue(s) matter most: ensuring the project gets access
to third-party improvements, protecting users' rights to study and
reverse engineer, or protecting users' rights to access the code and
make source-level modifications?

Is it important to have a license where the official distribution is
not privileged over third-party redistributions? (For example, LGPL
with an exception that allowed unlimited use of the library in
unmodified form would privilege me over third parties, since I would
be the only one who gets to decide what goes in the "unmodified"
version. Various commercial Open Source licenses have this issue, and
I believe even glibc's LGPL exception has this issue.)

Is the LGPL's handling of static linking problematic to you?

Are there other devil-in-the-details issues with the LGPL that you see
as problematic from a practical perspective of deploying musl? (Things
like technical issues making source available, informing the recipient
of their rights, etc.)

What would be your ideal license to see musl under?


Rich

Re: License survey

[Isaac Dunham]

On Sat, 18 Feb 2012 23:12:42 -0500
Rich Felker <dalias@aerifal.cx> wrote:

> Which is more important, copyleft or widespread usage of musl?
> 
> Which copyleft issue(s) matter most: ensuring the project gets access
> to third-party improvements, protecting users' rights to study and
> reverse engineer, or protecting users' rights to access the code and
> make source-level modifications?
> 
> Is it important to have a license where the official distribution is
> not privileged over third-party redistributions? (For example, LGPL
> with an exception that allowed unlimited use of the library in
> unmodified form would privilege me over third parties, since I would
> be the only one who gets to decide what goes in the "unmodified"
> version. Various commercial Open Source licenses have this issue, and
> I believe even glibc's LGPL exception has this issue.)
> 
> Is the LGPL's handling of static linking problematic to you?
> 
> Are there other devil-in-the-details issues with the LGPL that you see
> as problematic from a practical perspective of deploying musl? (Things
> like technical issues making source available, informing the recipient
> of their rights, etc.)
> 
> What would be your ideal license to see musl under?

For me, the main issue is whether the libc can be used in production of any binary. I don't see non-copyleft as necessary. 

Sabotage is completely static, so currently, you cannot legally distribute binaries for quite a few programs.

My own pick would be what FreePascal does: LGPL + static linking exception.
But I would like a license that says you need not worry about the libc license when distributing binaries linked against it.
As far as "official distributions" go, I would suggest that if you bother with such exceptions, you allow any distributor of your code or modified code to offer the same exception.
("If you did not modify the code from the version you received, and the version you received is pulicly available, you may refer the recipient to the place at which it is available instead of providing source.")
This basically covers those distributing binaries based on a distro's modified version.

Of course all exceptions may be dropped by a redistributor/fork.

By the way: tre has switched to BSD license, at NetBSD's request...
-- 
Isaac Dunham <idunham@lavabit.com>

Re: License survey

[gs]

On 02/19/2012 08:00 AM, Isaac Dunham wrote:
> On Sat, 18 Feb 2012 23:12:42 -0500
> Rich Felker<dalias@aerifal.cx>  wrote:
>
>>
>> What would be your ideal license to see musl under?
> For me, the main issue is whether the libc can be used in production of any binary. I don't see non-copyleft as necessary.
>
> Sabotage is completely static, so currently, you cannot legally distribute binaries for quite a few programs.
>
> My own pick would be what FreePascal does: LGPL + static linking exception.
> But I would like a license that says you need not worry about the libc license when distributing binaries linked against it.
> As far as "official distributions" go, I would suggest that if you bother with such exceptions, you allow any distributor of your code or modified code to offer the same exception.
> ("If you did not modify the code from the version you received, and the version you received is pulicly available, you may refer the recipient to the place at which it is available instead of providing source.")
> This basically covers those distributing binaries based on a distro's modified version.
>
> Of course all exceptions may be dropped by a redistributor/fork.
>
> By the way: tre has switched to BSD license, at NetBSD's request...
i second this, it should be possible to link musl statically to your app 
and distribute it without fear of license complaints.
there are not much propietary apps i care about, but those few i use 
currently link dynamically against glibc, which forces me to have its 
.so available even if the rest of my entire system is musl-linked.
it would be preferable if those would be entirely statically linked and 
could be used on any machine running a relatively recent linux kernel.

on the other hand modifications to musl itself should be made available 
publicly; if the license enforces this that's fine.

there are a number of libraries which use LGPL with static linking 
exception, like the ogre game engine which is in widespread use even for 
closed-source games.
i don't think the GNU in the name is a problem per se; at least one 
android device i recently had my hands on shipped with a bunch of LGPL 
licensed stuff (a samsung galaxy tab, there's a page about open-source 
licenses somewhere in the system settings).

Re: License survey

[Kurt H Maier]

I'd like to see musl released under a BSD or MIT license.  It's the only
way that musl can really stay free -- you've described the flaws in the
LGPL already.  The GPL creates a legal morass of restrictions and subtle
points of contention, which is what comes of wielding copyright law like
a club.  Obviously it's your decision, but I hope nobody here is under
the delusion that the GPL (and its descendants) represents software
freedom.  It boils down to "do what you will" vesus "do what I say," and
it's up to you if you want to reserve that right.

khm

Re: License survey

[Hiltjo Posthuma]

On Sun, Feb 19, 2012 at 8:27 AM, Kurt H Maier <khm@intma.in> wrote:
> I'd like to see musl released under a BSD or MIT license.

I concur fwiw.

Re: License survey

[Solar Designer]

On Sat, Feb 18, 2012 at 11:12:42PM -0500, Rich Felker wrote:
> Which is more important, copyleft or widespread usage of musl?

The latter, unless you intend to make money selling commercial licenses
(this would be a reason to have the publicly released musl copylefted).

> What would be your ideal license to see musl under?

Cut-down BSD, to the point of being copyright-only with no restrictions
at all - but using the same wording as the BSD licenses do for the
remaining portion of it.  That is:

<Copyright statements here>

Redistribution and use in source and binary forms, with or without
modification, are permitted.

<Warranty disclaimer here>

To me, this looks more obviously compatible with other Open Source
licenses than the usual N-clause BSD licenses are.  (Disclaimer: I am
not a lawyer.)

Alexander

Re: License survey

[Christian Neukirchen]

Rich Felker <dalias@aerifal.cx> writes:

> What would be your ideal license to see musl under?

I explained my thoughts on licensing (and anti-copyleft) at
http://chneukirchen.org/blog/archive/2009/08/why-i-use-the-mit-license.html

Main point:
> As long as there is a single available copy of free code, its freedom
> is kept and can be multiplied at no cost. For code that is worth
> anything, it will.

Also, please do not reword the BSD license.  If you want a minimal
version of it, use the ISC license: http://en.wikipedia.org/wiki/ISC_license
(I think having to keep the copyright note is a good idea, too.)

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: License survey

[Solar Designer]

On Sun, Feb 19, 2012 at 02:55:04PM +0100, Christian Neukirchen wrote:
> Also, please do not reword the BSD license.

I think that removing some or all clauses is not the same as rewording.
This has been done before when we went from 4-clause to 3-clause and
2-clause.  What I propose is 0-clause BSD.

That said, I do see some value in using a widespread license as-is.

> If you want a minimal
> version of it, use the ISC license: http://en.wikipedia.org/wiki/ISC_license

ISC license is my second best choice.

> (I think having to keep the copyright note is a good idea, too.)

I disagree; to me, the only good thing about this requirement is that it
is so common, so we can use an existing license template as-is.

ISC license says: "provided that the above copyright notice and this
permission notice appear in all copies."  I think this is somewhat
ambiguous and potentially problematic.  Does this copyright notice and
this permission notice have to appear inside a program binary statically
linked with libc under that license (thus including a copy of the libc
code)?  Does it have to appear in the documentation of such program?
The current practice would be that no, this would typically not be the
case - but is it valid per the license or not?  And should musl start to
provide such a const string for inclusion in all programs statically
linked against musl?  That would be +300 bytes to each binary (not
including the warranty disclaimer), and more once there are multiple
copyright holders to list.  Sure, that's not how we and others interpret
the license so far, so perhaps there's precedent that this is not
required - but strictly speaking that's not what the license says, and
not all countries have precedent law.

Disclaimer: I am not a lawyer.

Oh, and this does start to look like a bikeshed, so I think I won't
comment further.  I think Rich merely wanted us to vote, which we did. :-)

Alexander

Re: License survey

[Rich Felker]

On Sun, Feb 19, 2012 at 07:48:59PM +0400, Solar Designer wrote:
> Oh, and this does start to look like a bikeshed, so I think I won't
> comment further.  I think Rich merely wanted us to vote, which we did. :-)

This is totally a bikeshed, but sometimes the color you paint your
bikeshed matters when you live in a city full of biker gangs and
painting it the right or wrong color will determine who likes you and
who wants to kill you. :-)

And indeed, my main goal was to get a sampling of the opinions on
licensing from the community, and I think I've been successful in
that. Surely a lot more successful than any other time I'd asked for
input/opinions on this list.

A few thoughts I had myself on the matter...

One thing I like about copyleft and having external copyright holders
is that the rules apply to me too. If, for instance, I were working in
embedded systems as a job, and my employer asked me to prepare a
derived work of musl for purely-closed use, I could simply tell them
that's not possible without the consent of other copyright holders.
But with no copyleft, or if I'm the sole copyright holder, the choice
is pretty much to do it or quit (and if I do it, then of course there
becomes a contamination issue if I later try to make similar
improvements to the open version).

Another issue (I suspect Solar will feel differently than me about
this one) is the possibility of offering a non-free, closed version.
If I'm doing a BSD-licensed project and asking others to contribute
under BSD license, it feels like I'm taking their contributions to
build something I could turn around and make closed/commercial
derivatives of for my own benefit. And in a way it would be wrong to
deny myself the right to do this if everybody else who receives the
code has a right to do it, but the original author and/or project
maintainer is in a unique position of authority and trust that makes
it much easier to commercially exploit the code.

For these and of course all the more well-known, conventional reasons,
I tend to favor at least some sort of copyleft, but I also see that a
lot of the community and potential user base is worried about the
ugliness of LGPL with static linking, etc. I don't think there's a
quick and easy answer for what's best to do, but I'll keep everything
in mind as we move along.


Rich

Re: License survey

[Solar Designer]

On Sun, Feb 19, 2012 at 11:18:12AM -0500, Rich Felker wrote:
> One thing I like about copyleft and having external copyright holders
> is that the rules apply to me too. If, for instance, I were working in
> embedded systems as a job, and my employer asked me to prepare a
> derived work of musl for purely-closed use, I could simply tell them
> that's not possible without the consent of other copyright holders.
> But with no copyleft, or if I'm the sole copyright holder, the choice
> is pretty much to do it or quit (and if I do it, then of course there
> becomes a contamination issue if I later try to make similar
> improvements to the open version).

Wouldn't you also have the choice to tell your employer that you're
willing to let them use the code provided that you retain the right to
reuse any enhancements (or at least those you put in for them yourself)
in the free musl?  Of course, this permission (from the employer) will
need to be in writing - included in the same license agreement that lets
them use musl.  If they disagree, you don't let them use musl (and if
this somehow results in them not wanting to continue to employ you, then
you quit - I think I would).

For example, Openwall's standard contract agreement for professional
services says that we retain the right to reuse any enhancements that we
implement ourselves (of course, it is actually more verbose about that).
If a prospective client does not like that, we don't sign the contract
(or at least leave these kinds of work out of scope).

> Another issue (I suspect Solar will feel differently than me about
> this one) is the possibility of offering a non-free, closed version.
> If I'm doing a BSD-licensed project and asking others to contribute
> under BSD license, it feels like I'm taking their contributions to
> build something I could turn around and make closed/commercial
> derivatives of for my own benefit. And in a way it would be wrong to
> deny myself the right to do this if everybody else who receives the
> code has a right to do it,

Exactly: everybody receives that right, not just you.  All contributors
receive that same right to the entire thing.

> but the original author and/or project
> maintainer is in a unique position of authority and trust that makes
> it much easier to commercially exploit the code.

That unique position might be justified by you starting the project
and by the amount and nature of your contributions.  On the other hand,
if someone else contributes as much as you do, they may also be in a
similar position (no longer unique).  Ditto if someone makes a popular
fork, or if you retire from the project and someone else takes over
further maintenance.  Sounds fair to me.

In a sense, it's a question of "not have the benefit such that we're
sure we're being fair to every contributor (no one gets the benefit)"
vs. "have the benefit, but not be nearly so sure about distributing
it fairly (someone might get a disproportional share)".  Once we
consider that this benefit might enable the project to evolve faster
(e.g., enable you and maybe other key/major contributors to dedicate
more time to it), then the second option feels better to me.  You can be
a saint, but do little good, or you can choose not to be a saint, but do
some more good overall.

> I don't think there's a quick and easy answer for what's best to do

This definitely involves some non-trivial tradeoffs, yet some of us were
able to make specific suggestions, as you can see.  To me, it appears
that non-copyleft wins in terms of raw vote count.

Alexander

Re: License survey

[Kurt H Maier]

On Sun, Feb 19, 2012 at 11:18:12AM -0500, Rich Felker wrote:
>
> One thing I like about copyleft and having external copyright holders
> is that the rules apply to me too.

License choice and copyright assignment are two different issues.  If
musl continues with a copyleft license, I'll be slightly disappointed
and that's about it.  If copyright is assigned to the FSF, it's going to
become terrible, just like everything else the FSF touches.  If
copyright were assigned to some arbitrary mediator just to shield you
from liability at work, I'd be less concerned... but the FSF is where
software goes to lose its mind.

Re: License survey

[Rich Felker]

On Sun, Feb 19, 2012 at 05:25:31PM -0500, Kurt H Maier wrote:
> On Sun, Feb 19, 2012 at 11:18:12AM -0500, Rich Felker wrote:
> >
> > One thing I like about copyleft and having external copyright holders
> > is that the rules apply to me too.
> 
> License choice and copyright assignment are two different issues.  If
> musl continues with a copyleft license, I'll be slightly disappointed
> and that's about it.  If copyright is assigned to the FSF, it's going to
> become terrible, just like everything else the FSF touches.  If
> copyright were assigned to some arbitrary mediator just to shield you
> from liability at work, I'd be less concerned... but the FSF is where
> software goes to lose its mind.

"External copyright holders" purely meant code written by contributors
other than myself, not any sort of copyright assignment. As far as I'm
concerned copyright assignment is counterproductive and one of the
stupidest practices associated with FLOSS development, so no need to
worry about that.

Rich

Re: License survey

[Kurt H Maier]

On Sun, Feb 19, 2012 at 05:51:22PM -0500, Rich Felker wrote:
> As far as I'm
> concerned copyright assignment is counterproductive and one of the
> stupidest practices associated with FLOSS development, so no need to
> worry about that.


Great news, then, no matter what else you decide!

Re: License survey

[Isaac Dunham]

For the record, there is a public domain libc that supports Linux and can
 be used to build GCC on some platforms (ie known to work on mainframes): 
pdclib (from the PDOS project on sourceforge)
It's ANSI C89 only, though.


Rich Felker <dalias@aerifal.cx> wrote:
> One thing I like about copyleft and having external copyright holders
> is that the rules apply to me too. If, for instance, I were working in
> embedded systems as a job, and my employer asked me to prepare a
> derived work of musl for purely-closed use, I could simply tell them
> that's not possible without the consent of other copyright holders.
..
> Another issue (I suspect Solar will feel differently than me about
> this one) is the possibility of offering a non-free, closed version.
> If I'm doing a BSD-licensed project and asking others to contribute
> under BSD license, it feels like I'm taking their contributions to
> build something I could turn around and make closed/commercial
> derivatives of for my own benefit. 
.. 
LGPL +static linking exception for now, and review later?
Or just stick with LGPL?

-- 
Isaac Dunham <idunham@lavabit.com>

Re: License survey

[Rich Felker]

On Wed, Feb 22, 2012 at 09:51:15AM -0800, Isaac Dunham wrote:
> For the record, there is a public domain libc that supports Linux and can
>  be used to build GCC on some platforms (ie known to work on mainframes): 
> pdclib (from the PDOS project on sourceforge)
> It's ANSI C89 only, though.

Have you tried it? Last time I looked at this is seemed very
incomplete, non-conformant in what it did support, and abandoned...

Rich

Re: License survey

[Luka Marčetić]

On 02/19/2012 05:12 AM, Rich Felker wrote:
> What would be your ideal license to see musl under?

Hey Rich,
Ah, you know the implications of (non)copyleft as well as we do. I'd 
show the flaws in reasoning of those who advocate permissive licenses, 
but I'm getting tired of the discussion. Instead of philosophizing about 
how freedom to leech is bad (oops?), I'll just present a list of facts. 
You and I know this, and others do too, but if I try and be objective, 
maybe there's some perspective to be gained on either side. I hope both 
sides can agree that:

  ° Permissiveness has a potential for more contributors and bug reports *
  ° Permissiveness supports development of proprietary products
  ° Copyleft is somewhat harder to apply, harder still to properly 
explain **
  ° Copyleft ensures reciprocity via legal restrictions on derivatives
  ° GPLv3 adds restrictions on patents and tivoization

* Current trend is favoring permissive projects (Webkit, LLVM, 
web-related tech, Apache) over GPL'd ones (GCC, Linux). Apart from the 
hardworking BSD community, this may be caused by companies' FUD 
regarding GPL, or the exact opposite - their understanding of GPL. 
Hopefully, free software can emancipate from proprietary software makers 
in the future.
** Though some free help is available from SFLC, both for explaining and 
enforcing (GPL).

Entering the subjective mode again, just to address the second point. I 
am of opinion that companies, if enabled to produce non-free software 
based on free software, should at least compensate the community for it 
(or else, use another, possibly inferior, solution). In reality, 
however, the adoption by a commercial entity might be what brings you 
money. With that said, anything GPLv3-related is good in my book, but 
it's your decision. Not sure if this helps...

Good luck,
-Luka

Re: License survey

[aep]

> Is the LGPL's handling of static linking problematic to you? [...]

The lawyers and suits of a specific fortune 500 i will not name have 
sayd: "GPL<3 has sufficient loopholes that its ok to use it in our 
propriatary products, the rest we solve with patent suits."
GPL is a way to piss of the nice people and ineffective for the evil 
ones. Unless you go for GPL3.

In my opinion LGPL only makes sense if you want to go for dual 
licensing, selling the more liberal one for actual money. That's a tiny 
bit more complicated (reasigning every contribution, yadda yadda), but 
worth it.
Otoh, since i'm probably the only one evaluating musl for comercial 
software, not sure if that fits your target audience. If you're 100% 
sure you want to continue this as a 'hacker project', go 
MIT/BSD/whatever.
The GNU in GNU/Linux is a downhill project anyway. The only prople i 
see who can actually create a large FOSS project with musl are the guys 
around suckless (stali being one example),
and they're more appealed by BSD then GNU.

Personally I prefer commercial dual licensing with LGPL. LGPL itself is 
ok, if you let real lawyers handle it and its exceptions.
It's as ridiciously bloated as every GNU project, often leading to 
misinterpretation on either side. Hidden RMS agenda included. Just... 
ask a real lawyer.

/s/
Arvid


On Sat, 18 Feb 2012 23:12:42 -0500, Rich Felker wrote:
> Hey everyone,
>
> Lately there's been a lot of discussion on IRC about license issues,
> starting with Rob Landley's diatribe about acceptance on Android
> systems, and subsequent conversations on similar topics. While musl 
> is
> almost entirely code I've written and I'm not prepared to make any
> immediate changes, I'd like to hear from anyone in the community
> that's built up so far around musl as to what your views on licensing
> are and whether you'd want to see any changes in how musl is 
> licensed.
> Some questions to think about:
>
>
> Which is more important, copyleft or widespread usage of musl?
>
> Which copyleft issue(s) matter most: ensuring the project gets access
> to third-party improvements, protecting users' rights to study and
> reverse engineer, or protecting users' rights to access the code and
> make source-level modifications?
>
> Is it important to have a license where the official distribution is
> not privileged over third-party redistributions? (For example, LGPL
> with an exception that allowed unlimited use of the library in
> unmodified form would privilege me over third parties, since I would
> be the only one who gets to decide what goes in the "unmodified"
> version. Various commercial Open Source licenses have this issue, and
> I believe even glibc's LGPL exception has this issue.)
>
> Is the LGPL's handling of static linking problematic to you?
>
> Are there other devil-in-the-details issues with the LGPL that you 
> see
> as problematic from a practical perspective of deploying musl? 
> (Things
> like technical issues making source available, informing the 
> recipient
> of their rights, etc.)
>
> What would be your ideal license to see musl under?
>
>
> Rich

Re: License survey

[Solar Designer]

On Sun, Feb 19, 2012 at 05:03:08PM +0100, aep wrote:
> GPL is a way to piss of the nice people and ineffective for the evil 
> ones.

There are also nice people among proprietary software makers.  GPL works
to have them ask for an explicit commercial license (and offer something
in return).

> In my opinion LGPL only makes sense if you want to go for dual 
> licensing, selling the more liberal one for actual money.

That's a primary reason why I keep John the Ripper under GPLv2; for my
other software where I do not have such intent and do not mean to
discourage proprietary derivative works, I use 0-clause BSD now.

> That's a tiny 
> bit more complicated (reasigning every contribution, yadda yadda), but 
> worth it.

Copyright assignments have to be "in writing" (at least per US copyright
law), which may discourage many contributors.  Instead, I am considering
asking JtR contributors to license some of their contributions to me or
to Openwall with right to sublicense to arbitrary third-parties.  For
other contributions, which are more independent from the rest of the
code (separate source files), we use 0-clause BSD.  (The current major
contributors appear to be OK with these things.)  Things get pretty
complicated, though.  So I do not really recommend GPL for musl.

> If you're 100% 
> sure you want to continue this as a 'hacker project', go 
> MIT/BSD/whatever.

I second this.  In fact, being "100% sure" does not have to be a requirement.

Alexander

Re: License survey

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2012-02-18 23:12:42 -0500]:
> Which is more important, copyleft or widespread usage of musl?

i think the goal should be quality software that can be
audited, modified, maintained, studied and is useful

copyleft is not a goal, widespread usage should be a
side effect

> Which copyleft issue(s) matter most: ensuring the project gets access
> to third-party improvements, protecting users' rights to study and
> reverse engineer, or protecting users' rights to access the code and
> make source-level modifications?
> 
> Is it important to have a license where the official distribution is
> not privileged over third-party redistributions?
> 

i'd encourage sharing third party improvements
(and try to make it easy)
but would not try to enforce it
(except may be by publishing evildoers on a wall of shame)

i'd try to provide source code access, allow modifications etc
and signal that it will remain this way in the future

i'd allow binary or source code redistribution
with the only restriction that the origin of the information
must not be misrepresented and should be provided when asked
(but this should be dealt with by some general law against
fraud and not in individual licenses)

> Is the LGPL's handling of static linking problematic to you?

it haven't caused me problems yet, but i don't think it's practical

> What would be your ideal license to see musl under?

i don't mind lgpl and i don't mind non-copyleft licensing either

i support penalizing those who treat software as
private consumable instead of public good
i support punishing any evil non-cooperative
behaviour
but i'm not sure if licensing is the right place
to fight these
(it's more of a user education issue,
licensing is based on bogus ideology itself)

oh and i definitely don't want to litter precious
source code with legal nonsense (copyright notices)

Re: License survey

[Bobby Bingham]

On Tue, Feb 21, 2012 at 9:42 AM, Szabolcs Nagy <nsz@port70.net> wrote:
> [...]
> i'd encourage sharing third party improvements
> (and try to make it easy)
> but would not try to enforce it
> (except may be by publishing evildoers on a wall of shame)
>

This sounds like a contradictory position to me.

The whole point of a license is as a place for you to spell out your
requirements for others to use/redistribute the software.  If you want
them to share their improvements, that's exactly the sort of thing
that belongs in the license.

It sounds odd to me to use a license allowing others to keep their
improvements closed, and then to shame them for actually following the
license.

-- 
Bobby Bingham

Re: License survey

[Rich Felker]

On Tue, Feb 21, 2012 at 10:59:17AM -0600, Bobby Bingham wrote:
> On Tue, Feb 21, 2012 at 9:42 AM, Szabolcs Nagy <nsz@port70.net> wrote:
> > [...]
> > i'd encourage sharing third party improvements
> > (and try to make it easy)
> > but would not try to enforce it
> > (except may be by publishing evildoers on a wall of shame)
> >
> 
> This sounds like a contradictory position to me.
> 
> The whole point of a license is as a place for you to spell out your
> requirements for others to use/redistribute the software.  If you want
> them to share their improvements, that's exactly the sort of thing
> that belongs in the license.

Indeed, especially with corporate users. If you treat sharing
improvments as The Right Thing to do, but don't spell out a
requirement to do so, then people improving the source in a corporate
environment have their hands tied. They may want to share their
improvements, but without a legal requirement to do so, they're going
to have a really hard time convincing their boss and/or legal
department that it's a good idea. Ideally "It will save us having to
maintain our own tree internally and resolve conflicts merging
upstream changes." would be a good enough reason, but I think that's
wishful thinking...

> It sounds odd to me to use a license allowing others to keep their
> improvements closed, and then to shame them for actually following the
> license.

I'm uncertain whether I agree with this or not. All free software and
open source definitions seem to exclude any license that puts
restrictions on use based on field of endeavor (e.g. using the
software in controversial settings the copyright holder disagrees
with), but I would still feel perfectly comfortable shaming somebody
who used free software to censor the internet or track down dissidents
for imprisonment and torture.

In short, I think there's some merit to saying: I acknowledge that
it's not my right or responsibility to impose condition X on use of
code, because if we as a community tolerated that, everyone would come
up with their own pet conditions and combining code from different
projects would become impossible. But you're still a bad
person/company if you do [thing condition X would have prohibited].

Rich

Re: License survey

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2012-02-21 12:16:14 -0500]:
> On Tue, Feb 21, 2012 at 10:59:17AM -0600, Bobby Bingham wrote:
> > On Tue, Feb 21, 2012 at 9:42 AM, Szabolcs Nagy <nsz@port70.net> wrote:
> > > [...]
> > > i'd encourage sharing third party improvements
> > > (and try to make it easy)
> > > but would not try to enforce it
> > > (except may be by publishing evildoers on a wall of shame)
> > >
> > 
> > This sounds like a contradictory position to me.
> > 
> > The whole point of a license is as a place for you to spell out your
> > requirements for others to use/redistribute the software.  If you want
> > them to share their improvements, that's exactly the sort of thing
> > that belongs in the license.
> 
> Indeed, especially with corporate users. If you treat sharing
> improvments as The Right Thing to do, but don't spell out a

but i don't think sharing is "the right thing"

sometimes it's important sometimes it's not

i think licensing cannot protect against abusers
in general, so i mentioned the wall of shame

(i imagined wall of shame to be an objective source
of information: list of contributors, users, donators,
related projects, corporations, etc
from which somehow it becomes clear when someone uses
the project for personal gain without contributing
back anything

i'm not saying that it's practical/possible
to maintain such a list, but if it were there
then i could decide *myself* who i consider bad

to me this information seems more useful than the
legal protection: i can base future decisions on it
(legal protection allows me to sue, but who has
the resources to do that?)

right now the *author* tries to fix every
possible abuse in advance through licensing
so the author has a huge responsibility
when chosing the license
(instead of doing productive work))

> requirement to do so, then people improving the source in a corporate
> environment have their hands tied. They may want to share their
> improvements, but without a legal requirement to do so, they're going
> to have a really hard time convincing their boss and/or legal
> department that it's a good idea. Ideally "It will save us having to
> maintain our own tree internally and resolve conflicts merging
> upstream changes." would be a good enough reason, but I think that's
> wishful thinking...
> 

well this is another issue: many organizations are evil

organizations which are designed to compete
for the privatization of knowledge will
inevitably abuse public information

i don't want to fix this in the license
i don't think it can be fixed
(but i want to know it when it happens)

> > It sounds odd to me to use a license allowing others to keep their
> > improvements closed, and then to shame them for actually following the
> > license.
> 
> I'm uncertain whether I agree with this or not. All free software and
> open source definitions seem to exclude any license that puts
> restrictions on use based on field of endeavor (e.g. using the
> software in controversial settings the copyright holder disagrees
> with), but I would still feel perfectly comfortable shaming somebody
> who used free software to censor the internet or track down dissidents
> for imprisonment and torture.
> 
> In short, I think there's some merit to saying: I acknowledge that
> it's not my right or responsibility to impose condition X on use of
> code, because if we as a community tolerated that, everyone would come
> up with their own pet conditions and combining code from different
> projects would become impossible. But you're still a bad
> person/company if you do [thing condition X would have prohibited].
> 

this.

a license is either open to abuse or it limits
some legal uses along with the abusive ones

i'd like to err on the unrestricted side and
then fix the abuses with other tools

software licensing turns every author into moral
judges over what is right or wrong and then
hardcodes the judgement which will limit legal
uses just as well as abusive ones with no good
reason

Re: License survey

[Nathan McSween]

[-- Attachment #1: Type: text/plain, Size: 363 bytes --]

I would prefer an open license such as 2 clause BSD for a few simple points
- it gives musl a much needed niche for development (look at landley's
toybox development since it switched to BSD) and it's the path of least
resistance for any use case. BSD license may be use for closed use but in
my eyes usage (and hopefully development) far outweigh closed forks..

[-- Attachment #2: Type: text/html, Size: 377 bytes --]