| 1 |
Le 03/09/2009 23:27, Mounir Lamouri a écrit : |
| 2 |
> But the content of the license is the same. That only means you can use |
| 3 |
> a newer one. |
| 4 |
> I mean we do not need a new license file for that. It's up to upstream |
| 5 |
> to write somewhere if it's GPL-2 or GPL-2+, am I right ? |
| 6 |
|
| 7 |
Yes, that's for upstream to figure out. For instance, the kernel is |
| 8 |
GPL-2 only while some other pacakges are 2+. |
| 9 |
|
| 10 |
I don't want to sound like an ass, but that's why I think we shouldn't |
| 11 |
bother too much with LICENSE and all that stuff. |
| 12 |
|
| 13 |
We're not _lawyers_. None of us can guarantee that : |
| 14 |
1) the LICENSE field in our ebuilds are correctly set according to what |
| 15 |
upstream says. |
| 16 |
2) that the actual code of the package is indeed under that license and |
| 17 |
not tainted by some other code. |
| 18 |
|
| 19 |
For instance, I'm still working on migrating all the X11 packages to the |
| 20 |
"MIT" license (mainly for cleaning purposes), but in fact, each and |
| 21 |
every package should have its own license file (like today) because the |
| 22 |
MIT license requires that we acknowledge all major contributions to the |
| 23 |
code. Therefore, using a template like ${PORTAGE}/licences/MIT does is |
| 24 |
probably not a good idea from a legal point of view. |
| 25 |
|
| 26 |
And the X code being over 15 years old, only God knows who we should be |
| 27 |
thanking for this million lines of code. |
| 28 |
|
| 29 |
While you're idea is very nice on paper, actually doing it requires much |
| 30 |
_much_ more work than just adding operators and sets to portage. |
| 31 |
|
| 32 |
Rémi |
Archives