Copyright information is not available for some files

[Oleg Strikov]

Copyright information is not available for some files in different juju subpackages (juju, cmd, loggo, names, charm and others).
It prevents me from packaging 1.22 for vivid because we don't have permissions to redistribute content w/o copyright and license.

We should either have appropriate copyright information in the LICENSE file (this copyright will be applied to all files w/o copyright by default) or add appropriate copyright statement to all files w/o copyright. I think that the first option is much simpler so we just need to update LICENSE files of all problematic subpackages.

Please note that you may update just upstream versions of the licenses and I'll put a note and a link to this change into d/copyright. No changes in 1.22 are needed.

Hint: to find files w/o copyright notice you may use: $ grep -rLi copyright

NOTE that we probably want the scripts that make the release tarball to also verify each package has a LICENCE/LICENSE file that containers a copyright.

[Curtis Hovey (sinzui)]

The central concern of this issue is the ambiguity of ownership and licensing. ALL project have licences, but not all licences say who owns the copyright! We often see a generic licence file, then many files with copyright information. The owner of the files is not the owner of the licence. We can address the ambiguity by ensuring each project has a licence file that explains the copyright, then the licence (not the whole licence, just the paragraph that points to the licence). For example, the github.com/juju/charms/LICENCE file could be just this

    This package parses juju charms.
    Copyright (C) 2015 Canonical Ltd.

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU Affero General Public License as
    published by the Free Software Foundation, either version 3 of the
    License, or (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    GNU Affero General Public License for more details.

    You should have received a copy of the GNU Affero General Public License
    along with this program. If not, see <http://www.gnu.org/licenses/>.

[Eric Snow (ericsnowcurrently)]

Ah, thanks for clarifying Curtis. That makes sense and should be pretty easy to resolve.

[Cheryl Jennings (cherylj)]

I have updated the license files for the following repos:

https://github.com/juju/charm v4
https://github.com/juju/charm v5
https://github.com/juju/juju 1.22
https://github.com/juju/juju master
https://github.com/juju/loggo master
https://github.com/juju/names master
https://github.com/juju/testing 1.22
https://github.com/juju/testing master
https://github.com/juju/ratelimit master
https://github.com/juju/schema master
https://github.com/juju/txn master

[Oleg Strikov (strikov-deactivatedaccount)]

Thanks a lot Cheryl!
Could you update juju/utils as well. That's the last one :)
I prepared pull request and you may just merge it if you wish: https://github.com/juju/utils/pull/120

[Eric Snow (ericsnowcurrently)]

Just to be clear, the dependencies.tsv file will need to be updated in the 3 juju/juju branches to reference the updated revisions of the other repos.

In the case of 1.22 (and possibly but not likely 1.23) we need to be careful to not include undesired changes in those other repos. That means we may need to branch some of those other repos (where there are undesired changes) at the revision from 1.22's dependencies.tsv and update the LICENSE file in the new branch of the other repo (and update dependencies.tsv in 1.22 accordingly). That way the source release for 1.22 will include the correct LICENCE file for those other repos (which are included in the source release).

[Oleg Strikov (strikov-deactivatedaccount)]

I don't think that we really need to update anything except master branches.
If correct copyright/license is provided in upstream i can put a reference to it in debian/copyright.
Package itself won't include correct license but debian/copyright will tell you where to find correct one.

[Eric Snow (ericsnowcurrently)]

Ah, thanks for the clarification Oleg. Updating 1.23 appropriately won't be much work and for 1.22 only 3 dependencies make the situation slightly trickier. So expect we are still going to update the 1.22, 1.23, and master branches of the core juju repo to point to the revisions of the dependencies that have the updated LICENCE files.

[Casey Marshall (cmars)]

From https://www.gnu.org/licenses/gpl-howto.html:

You should also include a copy of the license itself somewhere in the distribution of your program. All programs, whether they are released under the GPL or LGPL, should include the text version of the GPL. In GNU programs the license is usually in a file called COPYING.

We should not remove the text copy of the AGPL from our projects, as that is recommended best practice by the FSF and there is no good reason to remove it IMO.

If I'm wrong, convince me that including the license is harmful.

[Casey Marshall (cmars)]

Also, to the original point in the bug, "not all licences say who owns the copyright" -- in my view, that's not what licenses do.

Licenses describe the legal terms of distribution, they don't declare the ownership.

However, if it helps, we can include Copyright 2015 Canonical Ltd. at the top the file to make this clear.

[Casey Marshall (cmars)]

We should not remove the existing license text. That is my main objection here. A URL isn't good enough.

[Cheryl Jennings (cherylj)]

The following repos have been updated with the latest agreed license changes:

github.com/juju/juju 1.22
github.com/juju/juju 1.23
github.com/juju/juju master
github.com/juju/txn master
github.com/juju/cmd master
github.com/juju/errors master
github.com/juju/testing 1.22 - (pending merge - unrelated build failure)
github.com/juju/testing master
github.com/juju/schema master
github.com/juju/loggo master
github.com/juju/names 1.22
github.com/juju/names master
github.com/juju/ratelimit master
github.com/juju/blobstore master
github.com/juju/charm 1.22 (pending merge)
github.com/juju/charm v4 (pending merge)
github.com/juju/charm v5 (pending merge)
github.com/juju/utils 1.22 (pending merge)
github.com/juju/utils master (pending merge)

Once all changes have been merged, I will update dependencies.tsv for juju/juju, starting with 1.22

[Oleg Strikov (strikov-deactivatedaccount)]

Thanks Cheryl!
I see that your pending commit to juju/charm switches the license from AGPL to LGPL.
This project officially used AGPL since Jun 10, 2014 (https://github.com/juju/charm/commit/fbf0be39609780a35bcf457a24efbb5c6d31ebf9)
Is it something expected?

[Cheryl Jennings (cherylj)]

Yes, we confirmed that the license for charm should be LGPL in this thread: https://lists.canonical.com/mailman/private/canonical-juju/2015-March/004719.html

Thanks for checking :)

[Aaron Bentley (abentley)]

Landed for 1.22.1 in https://github.com/juju/juju/pull/1982 and https://github.com/juju/juju/pull/1993

[Oleg Strikov (strikov-deactivatedaccount)]

Hi everyone,

I think that the text below this line is not needed and adds confusion:
https://github.com/juju/juju/blob/master/LICENCE#L626
License clearly states that we reached 'END OF TERMS AND CONDITIONS' and 'How to Apply' guidelines begin.
I don't think that 'How to Apply' sections is a part of the license.

It may be a reason of confusion because this 'How to Apply' guidelines state (again :) that:

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published by
the Free Software Foundation, EITHER VERSION 3 of the License, OR (AT YOUR OPTION) ANY LATER VERSION.

We put so much effort into this but 'any later version' part is still here (not so explicitly though).
How about removing this 'How to Apply' part?

[Cheryl Jennings (cherylj)]

Hi Oleg, The point that the "any later version" exists in the how to apply section was brought up and thought to be okay since it is clear that it exists after the end of the terms and conditions of the actual license which explicitly states v3 (and not later).

[Oleg Strikov (strikov-deactivatedaccount)]

Thanks Cheryl.
Okay, just wanted to make sure that you're aware of it.