Open GoogleCodeExporter opened 9 years ago
Well, the thing is that some people contribute to JPIP, other to JPWL, other to
MJ2, etc.
The differences are in the copyright, not the license (which should be always
2-clauses-BSD).
Ideas/suggestions on how to manage growing copyright notices in open-source
projects welcome.
Original comment by anto...@gmail.com
on 27 Mar 2014 at 9:46
Eg:
https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq#What_if_I_want_t
o_contribute_my_code_to_the_PSF.3F
Contributor should donate copyright to some kind of foundation (OpenJPEG
Foundation?).
Or else switch to Apache 2.0, which simplify the BSD handling.
Original comment by mathieu.malaterre
on 27 Mar 2014 at 9:52
Here is my proposition. Everyone who contribute to OpenJPEG should donate their
copyright to:
Copyright (c) 2002-2014, OpenJPEG contributors
Another alternative could be (if we want to keep the first contributor):
Copyright (c) 2002-2014, Universite catholique de Louvain (UCL), Belgium
Copyright (c) 2002-2014, OpenJPEG contributors
If we are ok with this, we can start pinging people to reply to this thread and
have their consents.
Original comment by mathieu.malaterre
on 8 Apr 2014 at 10:52
+1 for the solution:
Copyright (c) 2002-2014, Universite catholique de Louvain (UCL), Belgium
Copyright (c) 2002-2014, OpenJPEG contributors
Here is the list of the current contributors that have their name in one or
several copyrights :
Benoit Macq
David Janssens
Kaori Hagihara
Jerome Fimes
Giuseppe Baruffa
Mickaël Savinaud
Mathieu Malaterre
Yannick Verschueren
Herve Drolon
Francois-Olivier Devaux
Antonin Descampe
Centre National d'Etudes Spatiales (CNES), France
CS Systemes d'Information, France
Parvatha Elangovan
Jonathan Ballard
Callum Lerwick
Did I forget someone ?
Who shall we contact for CS and CNES ?
Original comment by anto...@gmail.com
on 10 Apr 2014 at 12:03
For reference, this happen to other project:
https://github.com/openseadragon/openseadragon/issues/58
Original comment by mathieu.malaterre
on 10 Apr 2014 at 12:17
I understand the simplification, you have my permission.
Original comment by mathieu.malaterre
on 10 Apr 2014 at 12:18
You have my permission as well.
Original comment by anto...@gmail.com
on 10 Apr 2014 at 12:24
Original comment by mathieu.malaterre
on 10 Apr 2014 at 12:26
Original comment by mathieu.malaterre
on 10 Apr 2014 at 12:26
you have my permission as well.
Benoit Macq
Original comment by Benoit.M...@gmail.com
on 10 Apr 2014 at 1:49
I do not agree with the simplification as stated above with the BSD license
that has two copyright lines, one for the university and one for contributors.
I believe an improved choice is given in the form of the Apache 2.0 license
since it is more effective in desired simplification with compatibility to
other licenses, licensors, and assignees. The BSD license with more than one
assignee is effectively the MIT license, which puts the terms within
educational bounds. In either case, the BSD license and MIT license limits
usage outside of educational code. That is often overlooked. We should allow
open usage of the source code instead of further impede application.
Jonathan Ballard
Original comment by dzona...@gmail.com
on 10 Apr 2014 at 6:15
Hello everybody !
It's nice to see that the OpenJPEG projects is developing so well.
Congratulations to all.
I understand the simplification proposed here. You have my permission !
Original comment by fodev...@gmail.com
on 11 Apr 2014 at 8:14
@dzonatas: AFAIU, the reason why you don't agree with the proposed
simplification is that in your opinion the Apache 2.0 license is better than
the BSD and OpenJPEG should adopt it. But this is another debate. The primary
purpose of the proposed simplification is only to ease the work of, for
instance, debian package managers when they have to gather all the different
copyrights from all the files in the project. It would be so much easier to
have the same license everywhere and AFAIK it does not change any right anyone
might have on the source code, compared to the current situation. If we agree
that a change from BSD to Apache is another (relevant) issue, do you think you
could reconsider your opinion on this very topic ? Let us know what you think.
Thanks,
Antonin.
Original comment by anto...@gmail.com
on 11 Apr 2014 at 1:44
The word "better" is not my opinion in regards to acceptance of Apache 2.0
license. The purpose of the Apache 2.0 license suits the needs in this topic
situation. I compromised my own personal choice and refrained from further
suggestion of my thought on superior licensing terms. I have no doubt that
Debian maintainers will also accept Apache 2.0 licensing terms, as it is
compatible with Debian Committee's choice of licenses.
I'm in favor of the single assignee if each contributor agrees that our name(s)
will be kept in (to be attached) contributor file along with opt-in choice of
accreditation. I am certain that meets this topic demand. For sample, in mean
time development of DWT optimizations, I accredit: American River College.
Jonathan Ballard
Original comment by dzona...@gmail.com
on 11 Apr 2014 at 2:34
@dzonatas Ok so in summary, you are ok with BSD single assignement:
Copyright (c) 2002-2014, OpenJPEG contributors
Even if this was not explicitly stated, we are of course keeping the AUTHORS
file as-is. If we missed anyone, here is your time to state it loud.
@antonin, do you know how hard it will be to have someone from Universite
catholique de Louvain (UCL), Belgium to agree to the copyright change ?
Original comment by mathieu.malaterre
on 11 Apr 2014 at 2:40
Hi to all,
I understand the need for license simplification.
You have my permission.
Hervé Drolon
FreeImage Team
Original comment by freeim...@aliceadsl.fr
on 11 Apr 2014 at 8:54
Hi,
I can't give my permission for this copyright modification. For different
reason:
Some of my work have been done under a contract with CNES so you need their
permission for this part of my work. In this case I am just author not the
copyright owner. It is the same for some work done during my CS-SI contract,
the copyright owner is my company. For the work done during my personal time, I
am the copyright owner. So it is quite difficult to give my permission.
Moreover the first point of the bsd claim that the above copyright notice could
not be modified.
The best way I think is to move to an Apache license and/or create steering
committee attach to a foundation with agreement acceptation before committing.
You can find a good example in the project Orekit
(https://www.orekit.org/forge/attachments/338/OREKIT_Governance.pdf)
Best
Original comment by savmick...@gmail.com
on 13 Apr 2014 at 10:02
@savmickael there is no difference at all whether we move to BSD asking you to
change the copyright change (this is legal for CS representative) or move to
Apache License.
In both case someone with CS representation need to give consent.
Original comment by mathieu.malaterre
on 14 Apr 2014 at 7:07
@dzonatas: Thanks for the effort you made to compromise your personal choice.
@mathieu: I do not know how hard it would be to have UCL agree on this. I check.
@savmickael: Moving to Apache license does not solve the copyright
simplification issue we're trying to fix here. Or am I missing sth ?
Original comment by anto...@gmail.com
on 14 Apr 2014 at 8:49
Answer from UCL regarding the single assignee proposition is that as initiator,
host, maintainer, funder, and main contributor of this project they want to
keep their name in the copyright. By the way, this is what is done in many
open-source projects, like OREKIT, mentioned by savmickael, which uses a NOTICE
file to credit contributions
(https://www.orekit.org/forge/projects/orekit/repository/revisions/master/entry/
NOTICE.txt).
@dzonatas: do you think you could live with the 2-assignees proposition and if
not, explain a bit more why do you think it would be bad/unfair ? Thanks.
@savmickael: do you know who we are supposed to contact to ask permission
regarding CS and CNES copyright ?
Original comment by anto...@gmail.com
on 15 Apr 2014 at 3:40
If UCL agreed to the single assignee, then we still need the single assignee
from UCL. "Universite catholique de Louvain (UCL), Belgium" does not constitute
the single assignee required by this BSD license.
Original comment by dzona...@gmail.com
on 16 Apr 2014 at 2:30
@dzonatas: I'm afraid I did not understand what you meant by "single assignee".
Could you explain why "Universite catholique de Louvain (UCL), Belgium" does
not constitute a valid assignee for BSD ? And if you would agree with the
proposition in comment #4, knowing the UCL position on that topic ? And if not,
could you write down what a suitable solution would be ? Thanks again.
Original comment by anto...@gmail.com
on 16 Apr 2014 at 9:46
@antonin: In comment #20, as stated, "they want to keep their name in the
copyright." The name given by UCL is only their accreditation, as demonstrated
in #14. If nobody else on the copyright is part of UCL, then that is the defect.
Original comment by dzona...@gmail.com
on 16 Apr 2014 at 2:26
@dzonatas: the copyright can be owned by the university on not necessarily by a
physical person. Then, in the AUTHORS, or THANKS, or NOTICE or whatever file,
we put the names of the people having effectively written down the code. It
does not appear to be a defect to me. Please explain further.
Original comment by anto...@gmail.com
on 17 Apr 2014 at 7:53
Copyrights are of the mind. We did not agree to the "UCL license."
Original comment by dzona...@gmail.com
on 17 Apr 2014 at 1:51
If we include an ARTIST file, we could represent the UCL copyright upon an
additional entity denotation, from unicode:
http://unicode-table.com/en/sections/enclosed-alphanumerics/ ( @antonin )
Sample solution: The latin-"capitol"-circle A would then be an entity as single
assignee for this artistic representation TO BE ASSIGNED (or underwritten) as:
"Copyright (c) 2002-2014, Universite catholique de Louvain (UCL), Belgium"
An ARTIST may insert the denotation for claims apart from BSD-AUTHORS.
This avoids an explicit reassignment against desired intention stated in #20.
The alternative, obvious to (BSD)UNIX folk, is fork() the front-end code.
[Down-Note: I do not consider QR-CODED condition statements in C-code as art.]
Jonathan Ballard
Original comment by dzona...@gmail.com
on 17 Apr 2014 at 7:42
In further research:
(1) In regards to OreKit, we have STEM, which has been mirrored globally:
www.whitehouse.gov/sites/default/files/microsites/ostp/stem_stratplan_2013.pdf
(2) Understanding STEM, we MAY enable default assignment by entities Ⓢ, Ⓣ,
Ⓔ, and Ⓜ for any claim or likewise rather than rely on single assignment.
I consider this the higher-level fork() without confusion of the question
"which university" is of mind.
(3) I neither opened nor looked at the kakadu source code despite of me
being held responsible for this code, and in spite of me unjustly and
relentlessly being called patent troll. I still have the original mail
message from one contracted OpenSim/SL contributor that linked me the
source code. I kept the linked zip file as evidence. In reality, the
lifting-scheme is minor in comparison to the patented cellular approach.
(4) The patented cellular approach is inevitable (to be implemented) with
appropriate levels of parallelism. Imagine how ⓈⓉⒺⓂ can help prevent
further division as in this issue.
(5) If we prevent further division, we SHOULD consider this issue an
enhancement rather than the defect as classified.
As the scientist, I neither judge, covet, nor indoctrinate us nor our
course of action. It is not me that any particular person does not
understand, yet (outside campus) I can refer back to (1).
[I earned my cup of coffee today.]
Original comment by dzona...@gmail.com
on 18 Apr 2014 at 12:31
@dzonatas: can we try to keep the solution (and the debate) as simple as
possible ? Could you state if you eventually agree with the solution hereunder ?
Copyright (c) 2002-2014, Universite catholique de Louvain (UCL), Belgium
Copyright (c) 2002-2014, OpenJPEG contributors
Many thanks.
Original comment by anto...@gmail.com
on 24 Apr 2014 at 12:37
Hello, for us (DSPLab - University of Perugia) it is OK to move to the new
copyright denomination suggested by Antonin.
Giuseppe
Original comment by giuseppe...@gmail.com
on 1 May 2014 at 8:31
Original issue reported on code.google.com by
mathieu.malaterre
on 27 Mar 2014 at 7:51