Hi Bjorn,
I do not want to work around.
I desperately try to get things right.
And looking at the silence from many other project leads,
it looks like
I'm one of few who desperatly try getting it right, so I
won't take a blame
for "working around". But in order to
get it right, it's much easier working
off a certified example.
For instance -
how is it correctly transcribed into plain
ASCII for feature.properties?
what about the list of licenses mentioned in
the SUA, if fewer licenses apply to a given feature?
do we really need to add plaintext of all
embedded licenses into feature.properties?
For instance, when projects transcribed the SUA from html
into plain ASCII they got it
wrong because a ™ entity was transcribed into "?"
rather than "(TM)". See
I honestly think that if we
all work off a blueprint, the chances of getting it right are
higher
(i.e. MUCH higher) than if every project tries to
interpret the "Guide to Legal Documents"
on its own.
The Platform has a long history of being the blueprint for
other projects, so I had hoped
finding a correct example there. But for me it looks like
it's also broken. Or am I wrong?
Martin,
Each project lead should concern himself or herself with
meeting the legal requirements for their particular project. While I
understand the desire to copy another project's files (prototype-based
programming at its best!), each project has a different legal situation - they
include different third-party packages, have different cryptography issues,
different source code and decompiler issues, etc. - and thus one project
cannot just copy another project's files. In other words, whether the Platform
project has the correct legal files should not be an issue for DSDP projects
(it is an issue for the EMO, but not for DSDP).
Secondly, there is a
nice certified example of all this in the Guide to Legal
Documentation: the directory structure of plug-ins and of features is
described (it even has indented trees of directories and sub-directories), and
the file contents of each file is described via prose and links. While no
document is every perfect, the descriptions in the Guide are pretty good. If
there are aspects of the documentation that are confusing or ambiguous to you,
please ask us for clarification and we'll be happy to help.
And
finally, we ask that you not just 'work around' these issues - for example, by
just copying another project's files and considering that good enough. These
legal issues may seem to be "pointless make work" to some, but they are, in
fact, essential - the larger Eclipse ecosystem relies on these legal processes
and part of Eclipse's wide adoption is due to our strict legal cleanliness. We
can work to make the processes better, but we cannot just not follow the
processes because we don't like them.
Thanks,
Bjorn
Am I reading you right that Platform will need to add
fulltext of the epl as well as ASCII fulltext of any other referenced 3rd
party licenses?
May I ask again for a certified example of a proper
feature including correct license.html, feature.properties, epl-v10.html and
anything else probably needed.
Does anybody of the Europa projects think they already
got it right so we could copy from
them?
