tech-pkg archive

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

Re: Please be careful when adding license tags



Jens Rehsack <rehsack%googlemail.com@localhost> writes:

> Greg Troxel wrote:
>> When adding LICENSE tags for Free software, please make sure that the
>> tag is listed in DEFAULT_ACCEPTABLE_LICENSES.  (Hopefully this problem
>> would show up when you do the test build prior to committing anyway :-)
>
> Please - let me ask to understand you correctly. Do you want that no
> LICENSE=abc is added to a package if that license isn't default acceptable?
> Or do you want that abc is added always to DEFAULT_ACCEPTABLE_LICENSES?

Neither!   Sorry, this just plain is hard.

Long ago, LICENSE= was messy, with things like "no-commercial-use" that
aren't licenses.  We had a grand cleanup over several years, where the
rule was that if a package had a license that was Free or Open Source,
it got no tag, and otherwise it got LICENSE=foo-license corresponding to
a file licenes/foo-license with an actual license.  That way Open
Source/Free software just built without setting anything, and non-free
software required placing ACCEPTABLE_LICENSES+= in mk.conf.

Now, we are trying to have the same default behavior - Open Source and
Free just build, but a) be precise about everything and b) let people
reject some Open Source licenses if they want.  Mostly (a) really - no
one with a use case of (b) has yet spoken up.

So, packages that have a Free/Open Source license now get LICENSE=foo
(No trailing -license in the name), but also all Free/Open Source
licenses should be in DEFAULT_ACCEPTABLE_LICENSES.

So the procedure to deal with a package w/o LICENSE is:

  Is the license Free or Open source?  (if so set FREE=true, else false)
  (Sorry, you have to figure this out before continuing.)

  Is the license in pkgsrc/licenses?

    YES: Check if -license suffix is present as it should be (if FREE,
    no -license suffix, else suffix.)

    NO: Add license as (FREE ? foo : foo-license).

  Is the license in DEFAULT_ACCEPTABLE_LICENSES?

     no: if FREE is false, that's good.  If FREE is true, add it.

     yes: if FREE is true, work already done, good.  If FREE is false,
     yell on tech-pkg - either you misjudged on FREE or the default is
     wrong.

  Add the license tag.

The intent is that if the license is Free or Open Source, adding the
license tag will not cause the package not to build.

>> Artistic 2.0 is both Open Source and free and Artistic (1) is only
>> Open Source (but not declared non-free):
>> 
>>  http://www.fsf.org/licensing/licenses/index_html#ArtisticLicense
>>  http://www.opensource.org/licenses/artistic-license-1.0.php
>> 
>> If the tag isn't in DEFAULT_ACCEPTABLE_LICENSES, please (in the case of
>> Free-ish software) either add it or instead raise the issue on tech-pkg.
>> Having LICENSE set to something not in DEFAULT_ACCEPTABLE_LICENSES
>> breaks automatic builds and updating.  (Of course, if the software isn't
>> free, a broken build is the right answer.)
>
> I'm no license expert and I do not presume which license is acceptable for
> someone or not. The author of DBD::Pg (Greg Sabino Mullane) declares the
> license under which the module can be distributed - regardless if we accept
> it per default or not.

Our rule is to look up the license with two authorities: Open Source
Institute and the Free Software Foundation.  If either approves, it goes
in the default.  Otherwise, we'll discuss and maybe add it if it's
essentially a free license.

> By the way - I do not understand why some licenses (e.g. GPLv2) are
> acceptable and others (vim's license) is not. But this is another discussion.

I've explained the rules, so either the vim license is non-free or we
are mishandling it.  I don't quite know which - it's messy because our
version doesn't have the version number, and the vim website has a
version with a preamble.  My best guess is we are mishandling it.

>> (This was triggered by running pkg_rolling-replace on a machine that
>> runs basically only apache/trac/svn/pgsql, and it errored out:
>> 
>> ===> Cleaning for p5-DBD-postgresql-2.13.1
>> ERROR: This package has set PKG_FAIL_REASON:
>> ERROR: p5-DBD-postgresql-2.13.1 has an unacceptable license: artistic-2.0.
>> ERROR:     To view the license, enter "/usr/bin/make show-license".
>> ERROR:     To indicate acceptance, add this line to /etc/mk.conf:
>> ERROR:     ACCEPTABLE_LICENSES+=artistic-2.0
>> *** Error code 1
>> 
>> I ran into this with some other package a few days ago.)
>
> Yes, that was my fault. Correct would be 'artistic OR gnu-gpl-v2' - I'll
> correct that (and I check all the other artistic-2.0 commits I made) to
> 'gnu-gpl-v2 #OR artistic'.

Presumably artistic-2.0, not artistic, and then only if it is explicitly
dual licensed.  I see that DBD-postgresql is licensed under either GPL
or Artistic.

I am personally not so concerned with expressing the dual licensing.  If
the culturarlly main license is artistic-2.0, and that's Free/Open, and
in DEFAULT_ACCEPTABLE_LICENSES, then LICENSE=artistic-2.0 doesn't cause
trouble.  But expressing OR licensing if our system is up to it seems
nice.

No worries - I was just writing because I know this is messy.

Attachment: pgpcPZybmh6Rg.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index