Joerg Sonnenberger <joerg@britannica.bec.de> writes:

> On Fri, Jun 15, 2007 at 09:53:12AM -0400, Greg Troxel wrote:

>> I agree conceptually; the question is about managing it.  If you want to
>> put the license fragment in the package's directory, then it merely
>> seems like file proliferation.
>> 
>> Or do you intend to put the NO_*_ON_* tags in the foo-license file in
>> licenses and extract them programmatically?  It would help to see a
>> full, concrete proposal for what you would like to see.
>
> Either way is fine with me. Attributing the license files directly has
> the advantage of less files, using a makefile fragment on the other hand
> makes it easier to use. I haven't written a full proposal because I
> didn't want to do it myself :-)

My view is further that we are not having any real pain due to the
current method of where the variables are.  Our problems are

1) some variables may be set wrong

2) (maybe): we don't have a good way to express that free CDs are permitted

>> Are you aware any non-free licenses beyond djbware and SCSL where the
>> *exact same* license is used by more than a few closely related packages?
>
> Does the classic BSD license with advertisement clause count? :-) I
> don't know.

No, it doesn't.  That license is both Open Source and Free.  It's not
GPL compatible, but that's not on the list of requirements to not have
LICENSE=.

>> I don't think we should get in the business of encoding use.  That's
>> outside of copyright law at least in the US.  The points of the current
>> scheme (not where variables are, but the semantics) are
>
> Be careful when arguing based on US law, as many (all?) bulk builders
> live in the old world.

I'm saying something more complicated, which is that I don't favor
actions beyond:

  marking packages with non-free licenses as a courtesy to people who
  choose to pay attention to licensing

  the minimum necessary to enable the project to distribute binary
  packages for non-free software in cases where the copyright holders
  permit such distribution

What people do with software once they have it is another story, but I
don't think pkgsrc should address that because there's no need.

>> 1) to leave the evaluation of the suitability of a non-free license with
>>    the user, where it must fundamentally rest since you, I and TNF
>>    aren't offering legal advice.  (The suitability of free licenses of
>>    course also rests with the user.)
>
> This is fine as long as (2) is kept. Encoding use is important for (2)
> though.
>
>> 2) to encode what kinds of distribution are permitted by the license so
>>    that the project and mirrors can refrain from distributing packages
>>    for which a copyright license to distribute has not been granted.

I don't think this requires worrying about encoding use.  Given a
license, one could ask the question: "is it permissible to make a binary
pkg available for free over the net to anyone who downloads it".  If the
license has terms like "can only distribute to people who won't use it
for X", then the answer is probably just "no".

> I do care about the following three cases:
> - distributing binary packages on a FTP server
> - handing out install/package/live CDs on fairs
> - handing out such CDs for a fee
> All such cases are fundamental for advocacy, so we should make it
> reasonable simple to do that.

So the only problem with the framework now given these needs is that
someone who wants to make a for-free CD and just use the tags has to
omit all NO_BIN_ON_CDROM packages, even though many of them could be
included.

Possible approaches:

1) Change the definition of NO_BIN_ON_FTP to be "cannot be distributed
at no charge via internet or physical media".  This might result in
dropping some packages from FTP distribution.

2) Live with having packages that can't be on copying-fee CDs not being
available.

3) Add a third variable.

  3a) add NO_BIN_ON_FREECDROM, and in one giant commit add it everywhere
  NO_BIN_ON_CDROM is set, and then let it be adjusted.

  3b) add OK_BIN_ON_FREECDROM, and set that to YES for packages that set
  NO_BIN_ON_CDROM and it's ok.  Let it default to the inverse of
  NO_BIN_ON_CDROM.

4) something more complicated, but I really do not yet see the point.


I favor 3b for now.