For Approval: German Free Software License
tg at 66h.42h.de
Fri Nov 26 13:15:53 UTC 2004
Michael Sparks dixit:
>Well at somepoint after date 4, all parties involved will be aware of GFSL
>1.732. At that point project B has to transform a GPL project from GPL to
>BSD in order to comply with the terms of section 3.3.1. This they cannot
>do since they also have to comply with section 3.3.
1) You can link D-FSL licenced code with BSD licenced code right
now as well, if I read the licence correctly.
If receiving a combined work, you must adhere to every single
licence in every single file anyway. (Think a typical BSD OS.)
2) There is no "the BSD licence", and it's author-specific, so
such a clause would be nonsense anyway.
3) What is so difficult for B to use not the code which A changed
to add BSD licenced code, but continue to use the D-FSL licenced
codebase as "vendor branch" (in CVS terms)?
>The GPL, BSD, AFL, OSL, lienceses guarantees that if I recieve code at any
>time under any of those licenses - specifically that if I recieve code at
>any time under and OSI certified license that I will be able to continue
>to use the source code as I see fit making derivative works as I need to
>under terms and conditions that do not change until copyright expiration.
Now now... what is so difficult in OSI certifying a specific instance
of the D-FSL as OSD conformant, and once a new version comes out and
you don't like the new version (or until it's OSI approved) you just
add a 10-liner you wrote yourself to it, placing it under GNU GPL?
Another alternative, though more compromising for the D-FSL authors,
would be to allow an older version to be still used (but disrecommen-
ded for new projects, and an upgrade option). There's the problem
though that, as often stated, we need less instead of more free
licences floating around (ok, I'm guilty too), and older versions of
specific licences add complexity to the problem. Maybe if the auto-
upgrade function would not be reduced to a manual (as in the GPL,
where you explicitly have to state "or any later..."),  but to a
semi-automatic upgrade, where this is already implied by the D-FSL
(and the boilerplate on each file states just the minimum D-FSL version
allowed) - this would require the D-FSL to allow linking to material
with any _larger_ version, though.
>Suppose however malice kicks in due to unfortunate political changes*, and
>(say) the license changes to remove the GPL clause, or the GPL clause
>changes to "you may not link with the GPL", etc.
See my comments above.
> This retroactively
>affects every external project that uses the code.
It's common sense that you cannot retroactively take back rights
granted under a published licence until the licence explicitly
> (Consider a whizzy new
>scheduler released under the GFSL which gets integrated into the linux
>kernel, the GFSL changes - the scheduler has to be removed - from all
No, since upon entering the Linux kernel it's automatically GPL'd.
>"As a new version of the License is published, you may choose to accept
>such version as binding as you become aware of its publication."
That's not enough, see  above.
>You really need to include the version number in the license though,
That has already been decided.
>change, and political climates in all countries change. You cannot
>guarantee to the list that the license may change 10 years from now to
>disallow any/all OSI rights.
Who does guarantee that the OSI will keep the OSD always conformant
to the spirit which lies beyond it right now?
> * This license is not Free Software as I would understand the
> definition used by most - most people tend to agree with the FSF
> these days out of convenience here.
> * This license is not Open Source - as most people would view things.
>> I will go back to work now.
Please read http://www.afaik.de/usenet/faq/zitieren/ (it has got
English and Nederlands translations linked there, too). Thanks!
//mirabile, waiting for the board's decision too
More information about the License-discuss