[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] New Update Manager UI : Your thoughts
|
To clarify my point, it was that if a plugin provider chooses to _require_
that the user acknowledge a license (this is the software equivalent of
signing a contract or signing a waiver absolving the provider of liability),
the UI should not be able to bypass that.
I don¹t think it necessarily needs to be that complex -- in line with
"keeping simple things simple'.
So a possibly more elegant solution would be that accepting a license _the
first time_ drops a digital signature locally. Any future updates from a
site that presents that same signature would not require acknowledgement
because it is in the local cache (similar to SSH keys, if you know what I
mean). This allows a one time agreement to the license. If the provider
decides to change the terms of the license and needs the user to acknowledge
it, he simply changes the signature he presents.
The beauty of this is, if you have an application with an installer it can
simply install the signature file and therefore the user would never be
prompted to accept an agreement by the software (he would have already
acknowledged it in the installer).
-Brett
On 6/13/07 1:28 PM, "Laidlaw, Don" <don.laidlaw@xxxxxxxxx> wrote:
> OK, lets step back and look at it differently.
>
> I don¹t think this would be illegal, but I am not a lawyer, and I don¹t play
> one on TV.
>
> Infor (the company writing the software) is using equinox server-side to
> assemble an ERP system at WidgetCo, the company that manufactures widgets.
>
> This is not an eclipse IDE of any kind.
>
> WidgetCo and Infor have a licensing agreement between them. WidgetCo has
> purchased a license for Infor¹s software and can receive free updates for 1
> year from the purchase date. Now, instead of automatically accepting license
> agreements, we have a more complex requirement, but a real one that needs a
> solution.
>
> Possible options:
>
> 1. There are update sites that are always trusted by the update manager. The
> user that sets the ³I trust this update site² flag must have in essence agreed
> to the license in advance. Such as free updates for a year as per a license
> agreement. In this case, Infor will stop populating the WidgetCo update site
> with new versions after a certain date, and the onus is on Infor to make this
> happen. Probably by getting a new license agreement signed. Very little needs
> to be done in the update manager in this case, except to trust sites that are
> marked as trusted. Notes could be added as to why it is trusted, perhaps.
>
> 2. The update sites in the update manager could have attached multiple license
> keys. These keys are transmitted to the update site with the update request.
> Now the update site is not a simple set of web pages and resources served by a
> apache. It needs to be a web application that can validate the license keys.
> The update site either sends the updates or rejects the request.
>
> 3. The update site provided by Infor could be behind a password protected URL.
> Access to this URL is only given to customers that have a signed license
> agreement. The license requirements are all handled outside of the scope of
> the update manager. The the update manager, the update site is marked as
> trusted.
>
> 4. Infor provides a password protected URL from which WidgetCo can download an
> update site that WidgetCo can host locally. Again, Infor and WidgetCo have the
> license agreement managed outside of the scope of the update manager. This
> downloaded and hosted update site is marked as trusted.
>
> In all cases, the marking of an update site as trusted means that all license
> management is being handled outside of the update manager. And the act of
> marking an update site as trusted means that the administrator has agreed that
> all licenses required at that site are already handled outside of update
> manager.
>
> An update site should have the ability to override this and say: ³Never allow
> update manager to trust me². This could even be the default.
>
> Without introducing a full blown license management system, we cannot get too
> complex in the requirements here. But server-side implementations will require
> the ability to trust some update sites and not need license agreements
> individually agreed to. If only because sometimes there will be no human and
> no UI present when the update happens.
>
> -Don
>
>
> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile:
> 416-543-1085 | don.laidlaw@xxxxxxxxx
>
> On 6/13/07 11:56 AM, "Brett Wooldridge" <bwooldridge@xxxxxxxxxxxxxx> wrote:
>
>> I think there are legal ramifications, at least in the United States for
>> that. While we¹re all annoyed by licenses, I don¹t think you can
>> ³auto-dismiss them² any more than you can stamp your car loan with your
>> signature.
>>
>> -Brett
>>
>> On 6/13/07 8:59 AM, "Laidlaw, Don" <don.laidlaw@xxxxxxxxx> wrote:
>>
>>>
>>> True, but it can also be a policy of a plugin consumer to accept the
>>> licenses of trusted update sites. Then the consumer only has to determine
>>> which update sites will always be trusted.
>>>
>>> In using equinox on the server side, the update sites will usually be in the
>>> same company.
>>>
>>> -Don
>>>
>>> Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 | mobile:
>>> 416-543-1085 | don.laidlaw@xxxxxxxxx
>>>
>>> On 6/13/07 9:55 AM, "Peter Manahan" <manahan@xxxxxxxxxx> wrote:
>>>
>>>>
>>>> The need for license acceptance is typically a requirement discretion of
>>>> the plugin provider and not the consumer of the plugins. So allowing the
>>>> consumer to disable the license acceptance should only be optional at the
>>>> discretion of the plugin provider.
>>>>
>>>> Peter
>>>>
>>>> equinox-dev-bounces@xxxxxxxxxxx wrote on 06/13/2007 09:04:39 AM:
>>>>
>>>>>
>>>>> The provisioning system should already know about the sites and
>>>>> should be able to discover more.
>>>>>
>>>>> Actually I missed in there where the users said which plugin they wanted.
>>>>>
>>>>> User should not have to accept a license if the plugin is coming
>>>>> from a known/trusted site. Sites should be ranked in this way
>>>>>
>>>>> Restart may not be needed
>>>>>
>>>>> Jeff
>>>>>
>>>>>
>>>>
>>>>>
>>>>> "Prashant Deva" <prashant.deva@xxxxxxxxx>
>>>>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>>>>> 06/12/2007 08:26 PM
>>>>>
>>>>> Please respond to
>>>>> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>>>>>
>>>>> To
>>>>>
>>>>> "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
>>>>>
>>>>> cc
>>>>>
>>>>> Subject
>>>>>
>>>>> Re: [equinox-dev] New Update Manager UI : Your thoughts
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ok, here is some thoughts on the gui for installing a new plugin.
>>>>> This is in keeping with the philosophy of keeping the simple things
>>>>> simple.
>>>>> I wish there were a place where I could upload some docs and sample
>>>>> images to make the point more clear, but i will just type some stufffor
>>>>> now.
>>>>>
>>>>> 1. User clicks on 'Install new plugin' button
>>>>> 2. Dialog box with single text field asks to enter the url of
>>>>> pluign update site.
>>>>> 3. update manager automatically gets the latest available
>>>>> version of the plugin.
>>>>> 4. asks the user to accept the license.
>>>>> 5. if license accepted, then installs plugin and asks user
>>>>> torestart.
>>>>>
>>>>> The update site url, etc are automatically saved by the program and
>>>>> user doesnt need to give a 'name' along with the url as we have to do now.
>>>>> Also no dialog box for confirming 'install all'. All user has to
>>>>> enter is the url and accept the license.
>>>>>
>>>>> the dialog in step 2 can have an 'advanced' button, which when
>>>>> selected allows user to choose the exact version to install.
>>>>>
>>>>> your thoughts? any compulsory steps in the install process we might
>>>>> be missing this way?
>>>>>
>>>>> prashant_______________________________________________
>>>>> equinox-dev mailing list
>>>>> equinox-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>> _______________________________________________
>>>>> equinox-dev mailing list
>>>>> equinox-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> equinox-dev mailing list
>>>> equinox-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>>
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
